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INTFODUCnCW 


The  Ada  inplementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  (Pro90]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Con?)iler  Validation  Capability  (ACVC).  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  t^e  testing  of  this  Ada  implementation. 

For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
(Pro90].  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  (UG89]. 


1.1  USE  OF  THIS  VALIDATICXJ  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  resxilts  of  this  validation  apply 
only  to  the  con^juters,  operating  systems,  eind  compiler  versions  identified 
in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 


Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  vrtiich  performed  this  validation  or  to: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria  VA  22311 
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1.2  REFERENCES 

[Ada83]  Reference  Meunual  for  the  Ada  Progrzmnninq  Language, 

ANSI/MIIr-SlD-lSlSA,  February  1983  and  ISO  8652-1^87. 

(Pro901  Ato  Compiler  Validation  Procedures »  Version  2.1,  Ada  Joint  Program 
Office,  August  1990. 

[UG89]  Ada  Ccanpiler  Validation  Capability  User^s  Guide,  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Conpliance  of  Ada  in^lementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
vhich  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B  and 
class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  resiilt  vdien  they 
are  executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13, 
and  the  procedure  CHECK  FILE  are  used  for  this  purpose.  The  package  REPORT 
also  provides  a  set  of  Identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of 
text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  conpiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  conpiled  and  the 
res\jlting  conpilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  vdiich  must  not  be  flagged  illegal  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  inplementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors 
are  expected  at  link  time,  a^  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
inplementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  iised  for  this  inplementation  is  provided  in  ^pendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
inplementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  aistomized  test  suite  is  produced  by  the 
AVF.  This  customization  consists  of  making  the  modifications  described  in 
the  preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1)  and, 
possibly  some  inapplicable  tests  (see  Section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  inplementation  must  process  each  test  of 
the  customized  test  siiite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Conpiler  The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  conpjter  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 

Ada  Compiler  ihe  means  for  testing  compliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  and  the  tenplate  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  compiler  with  its  host  conpjter  system  and  its 

Inplementation  target  conputer  system. 

Ada  Joint  ihe  part  of  the  certification  body  vrtiich  provides  policy  and 
Program  guidance  for  the  Ada  certification  system. 

Office  (AJFO) 

Ada  Hie  part  of  the  certification  body  v^ich  carries  out  the 

Validation  procedures  required  to  establish  the  conpliance  of  an  Ada 
Facility  (AVF)  inplementation. 

Ada  Hie  part  of  the  certification  body  that  provides  technical 

Validation  guidwce  for  operations  of  the  Ada  certification  system. 


Compliance  of  The  ability  of  the  inplementation  to  pass  an  ACVC  version. 


Computer  A  functional  unit,  consisting  of  one  or  more  computers  and 

System  associated  software,  that  uses  connnon  storage  for  all  or 

part  of  a  program  and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
computer  system  may  be  a  stand-alone  unit  or  may  consist  of 
several  inter-connected  units. 
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Conformity  Fulfillment  by  a  product,  process  or  service  of  all 
requirements  specified. 

Customer  An  individual  or  corporate  entity  vho  enters  into  an 

agreement  with  an  AVF  which  specifies  the  terms  and 
conditions  for  AVF  services  (of  any  kind)  to  be  performed. 

Declaration  of  A  formal  statement  from  a  customer  assuring  that  conformity 

Conformance  is  realized  or  attainable  on  the  Ada  in(>lementation  for 
which  validation  status  is  realized. 

Host  Computer  A  conpiter  system  vdiere  Ada  source  programs  are  transformed 

System  into  executable  form. 

Inapplicable  A  test  that  contains  one  or  more  test  objectives  found  to  be 

test  irrelevant  for  the  given  Ada  implementation. 

ISO  International  Organization  for  Standardization. 

Operating  Software  that  controls  the  execution  of  programs  and  that 

System  provides  services  such  as  resource  allocation,  scheduling, 

input/output  control,  and  data  management.  Usxially, 
operating  systems  are  predominantly  software,  but  partial  or 
conplete  hardware  implementations  are  possible. 

Target  A  computer  system  \diere  the  executable  form  of  Ada  programs 

Computer  are  executed. 


Validated  Ada  the  compiler  of  a  validated  Ada  implementation. 


Validated  Ada  An  Ada  implementation  that  has  been  validated  successfully 
Implementation  either  by  AVF  testing  or  by  registration  [ Pro90 ] . 

Validation  Ihe  process  of  checking  the  conformity  of  an  Ada  compiler  to 
the  Ada  programmiing  language  and  of  issuing  a  certificate 
for  this  implementation. 

Withdrawn  A  test  found  to  be  incorrect  and  not  used  in  conformity 
test  testing.  A  test  miay  be  incorrect  because  it  has  an  invalid 

test  objective,  fails  to  meet  its  test  objective,  or 
contains  erroneous  or  illegal  use  of  the  Ma  programmiing 
language. 
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2.1  WITHDRAMN  TESTS 

Hie  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  withdrawn  tests  is  2  August  1991. 


E28005C 

B28006C 

C32203A 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

Cr74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C9402U 

C:97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

ca223A 

Ba226A 

Ca226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

a)3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD900SA 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 
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2.2  INAPPLICABLE  TESTS 


A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant 
for  a  given  implementation.  Reasons  for  a  test's  inapplicability  may 
be  supported  by  documents  issued  by  the  ISO  and  the  AJFO  known  as  Ada 
Commentaries  a^  conanonly  referenced  in  tl%  format  Al-ddddd.  For  this 
iiqplementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  inclivied  as 
appropriate. 


The  following  201  tests  have  floating-point  type  declarations 
requiring  more  digits  than  SYSTEH.MAX_DIGITS : 


C24113L..Y  (14  tests) 
C35706L..y  (14  tests) 
C35708L..Y  (14  tests) 
C45241L..Y  (14  tests) 
C45421L..Y  (14  tests) 
C45524L..Z  (15  tests) 
C45641L..Y  (14  tests) 


C35705L..Y  (14  tests) 
C35707L..Y  (14  tests) 
C35802L..Z  (15  tests) 
C45321L..Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 
C46012L..Z  (15  tests) 


The  following  20  tests  check  for  the  predefined  type  LCNG_INTEGER;  for 
this  inplementation,  there  is  no  such  type: 


C35404C  C45231C 
C45502C  C45503C 
C45613C  C45614C 
C55B07A  B55B09C 


C45304C 

C45504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C35713B^  C45423B,  B86001T,  and  C86006H  check  for  the  predefined  type 
SHORT_FLQAT;  for  this  implementation^  there  is  no  such  type. 

C357130  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  LGNG_FLQAT,  or  SHORT_FLQAT;  for  this 
implementation,  there  is  iM  such  type. 

C4553in..F  and  C45532M..F  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. HAX_MANTISSA  of  47  or  greater;  for  this 
ioplementation,  MAX_NANTISSA  is  less  than  47. 

C45536A,  C46013B,  C46031B,  C46033B,  and  C46034B  contain  length  clauses 
that  specify  values  for  'SHALL  that  are  not  powers  of  two  or  ten;  this 
implementation  does  not  siqiport  such  values  for  'SHALL. 

C45624A. .B  (2  tests)  check  that  the  proper  exception  is  raised  if 
HACHINEjOVERFLOHS  is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outside  the  range  of  the  base 
type;  for  this  inplementation,  HACHINE_0VERFLCM5  is  TRUE. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
OURATIGN;  for  this  isplementation,  there  is  no  such  type. 
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CD1009C  checks  whether  a  length  clause  can  specify  a  non-de£a\ilt  size 
for  a  floating-point  type;  this  implementation  does  not  support  such 
sizes. 

CD2A53A  checks  operations  of  a  fixed-point  type  for  which  a  length 
clause  specifies  a  power-of-ten  TYPE' SMALL;  this  implementation  does 
not  siipport  decimal  'SMALLs.  (See  section  2.3.) 

CD2A84Ar  CD2A84E,  CD2AB4I..J  (2  tests),  and  CD2AB40  use  length  clauses 
to  specify  non-defaiilt  sizes  for  access  types;  this  inplementation 
does  not  sii^^rt  such  sizes. 

BD8001A,  BD8003A,  BD8004A. .B  (2  tests),  and  ADSOllh  use  machine  code 
insertions;  this  inplementation  provides  no  package  MACHINE_CODE. 

The  tests  listed  in  the  following  table  check  that  USE_EBROR  is  raised 
if  the  given  file  operations  are  not  supported  for  the  given 
combination  of  mode  and  access  method;  this  implementation  supports 
these  operations. 


Test  File  Operation  Mode  File  Access  Method 


CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  10 

CE2102F 

CREATE 

INOOT  FILE 

DIRECT  10  - 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE2102O 

RESET 

IN  FILE 

SBQUENTTAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPElt 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OUT_FILE 

DIRECT_IO 

CE3102F 

RESET 

Any  Mode 

TEXT_IO 

CE3102G 

deileite 

TEXT_IO 

CE3102I 

CREATE 

OUT  FILE 

TEXT_IO 

CE3102J 

OPEN 

IN  FILE 

TEXT_IO 

CE3102K 

OPEN 

OOT  FILE 

TEXT  10 

The  tests  listed  in  the  following  table  check  the  given  file 
operations  for  the  given  combination  of  mode  and  access  method;  this 
inplementation  does  not  support  these  operations. 


Test  File  Operation  Mode  File  Access  Method 


IN_FILE  SEQUENnAL_10 
IN_FILE  DIRECT_IO 

IN  FILE  TE3CT  10 


CE2105A 

CE2105B 

CE3109A 


CREATE 

CREATE 

CREATE 
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CE2401H,  EE2401D,  and  EE2401G  use  instantiations  of  DIR£CT_IO  with 
unconstrained  array  and  record  types;  this  implementation  raises 
USE_EBRDR  on  the  atteiq)t  to  create  a  file  of  such  types. 

CE2203A  checks  that  V?RITE  raises  U5E_ERROR  if  the  capacity  of  an 
external  sequential  file  is  exceeded;  this  implementation  cannot 
restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERBOR  if  the  capacity  of  an 
external  direct  file  is  exceeded;  this  implementation  camot  restrict 
file  capacity. 

CE3202A  expects  that  function  NAME  can  be  applied  to  the  standard 
input  and  output  files;  in  this  inplementation  these  files  have  no 
names,  and  USE_ERBOR  is  raised.  (See  section  2.3.) 

CE3304A  checks  that  SET_LINE^LENGTH  and  SET_PAGE_LENGTH  raise 
USE_ERROR  if  they  specify  an  Tnappropriate  value  for  the  external 
file;  there  are  no  inappropriate  values  for  this  implementation. 

CE3413B  checks  that  PAGE  raises  LAYOUT  ERROR  when  the  value  of  the 
page  number  exceeds  COUNT' LAST;  for  this  Tnplementation,  the  value  of 
COUNT' LAST  is  greater  than  150000,  making  the  checking  of  this 
objective  inpractical. 


2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  23  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
inplementation  did  not  report  the  violations  of  the  Ada  Standard  in  the 
way  expected  by  the  original  tests. 


B23004A 

B24007A 

B24009A 

B28003A 

B32202A 

B32202B 

B32202C 

B37004A 

B61012A 

B74401F 

B74401R 

B91004A 

B95032A 

B95069A 

B95069B 

BAllOlB 

BC2001D 

BC3009C 

B85002A  was  graded  passed  by  Evaluation  Modification  as  directed  by  the 
AVO.  This  test  declares  a  record  type  REC2  whose  sole  conponent  is  of  an 
unconstrained  record  type  with  a  size  in  excess  of  2**32  b^es;  this 
inplementation  rejects  the  declaration  of  REC2.  Although  a  strict 
interpretation  of  the  LRM  requires  that  this  type  declaration  be  accepted 
(an  exception  may  be  raised  on  the  elaboration  of  the  type  or  an  object 
declaration),  the  AVO  accepted  this  behavior  in  consideration  that  such 
early  error  detection  is  expected  to  be  allowed  by  the  revised  language 
stan^rd. 
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BA2001E  was  graded  passed  by  Evaluation  Modification  as  directed  by  the 
AVO.  The  test  expects  that  duplicate  names  of  subunits  with  a  common 
ancestor  will  be  detected  as  con^ilation  errors;  this  in^lementation 
detects  the  errors  at  link  time,  and  the  AVO  ruled  that  this  behavior  is 
acceptable. 

EA3004D  was  graded  passed  by  Evaliiation  and  Processing  Modification  as 
directed  by  the  AVO.  The  test  requires  that  either  pragma  INLINE  is 
obeyed  for  a  function  call  in  each  of  three  contexts  and  that  thus  three 
library  units  are  made  obsolete  by  the  re-ccopilation  of  the  inlined 
function's  body,  or  else  the  pragma  is  ignored  ccnpletely.  This 
inplementation  obeys  the  pragma  except  when  the  call  is  within  the  package 
specification.  When  the  test's  files  are  processed  in  the  given  order, 
only  two  units  are  made  obsolete;  thus,  the  expected  error  at  line  27  of 
file  EA3004D6M  is  not  valid  and  is  not  flagged.  To  confirm  that  indeed 
the  pragma  is  not  obeyed  in  this  one  case,  the  test  was  also  processed 
with  the  files  re-ordered  so  that  the  re-conpilation  follows  only  the 
package  declaration  (and  thus  the  other  library  units  will  not  be  made 
obsolete,  as  they  are  compiled  later);  a  "NOT  APPLIG^LE"  result  was 
produced,  as  expected.  The  revised  order  of  files  was  0-1-4-5-2-3-6. 

CD2A53A  was  graded  inapplicable  by  Evaliaation  Modification  as  directed  by 
the  AVO.  The  test  contains  a  specification  of  a  power-of-10  value  as 
'SMALL  for  a  fixed-point  type.  The  AVO  ruled  that,  under  ACVC  1.11, 
support  of  decimal  'SMALLs  may  be  omitted. 

CE3202A  was  graded  inapplicable  by  Evaluation  Modification  as  directed  by 
the  AVO.  This  test  applies  function  NAME  to  the  standard  ii^t  file, 
v^ich  in  this  inplementation  has  no  name;  USE_ERBOR  is  raised  but  not 
handled,  so  the  test  is  aborted.  The  AVO  ruled  that  this  behavior  is 
acceptable  pending  any  resolution  of  the  issue  by  the  ARC. 
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PROCESSING  INFOI^TION 


3.1  TESTING  ENVIRCMIENT 

The  Ada  inplementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  a  point  of  contact  for  technical  or  sales  information  ediout  this  Ada 
in^lementation  system,  see: 

Marianne  Mardesich 
California  Language  Lab 
19447  Pruneridge  Avenue 
Cupertino  CA  95014 
(408)  447-6973 

Testing  of  this  Ada  inpleraentation  was  conducted  at  the  customer's  site  by 
a  validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS  - 

An  Ada  Iirplementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Progreunming 
Language  Standard,  v4iether  the  test  is  applicable  or  inapplicable; 
otherwise,  the  Ada  In5)lementation  fails  the  ACVC  [Pro90]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was 
obtained  that  conforms  to  the  Ada  Programroi^'g  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various 
categories.  All  tests  were  processed,  except  those  that  were  withdrawn 
because  of  test  errors  (item  b;  see  section  2.1),  those  that  require  a 
floating-point  precision  that  exceeds  the  implementation's  maximum 
precision  (item  e;  see  section  2.2),  and  those  that  depend  on  the  support 
of  a  file  system  —  if  none  is  supported  (item  d).  All  tests  passed, 
except  those  that  are  listed  in  sections  2.1  and  2.2  (counted  in  items  b 
and  f,  below). 
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a)  Total  Number  of  Applic2d3le  Tests  3791 

b)  Total  Number  of  withdravm  Tests  95 

c)  Processed  Inapplicable  Tests  83 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 

f)  Total  Number  of  Inapplicable  Tests  284 


g)  Total  Number  of  Tests  for  ACVC  1.11  4170 


3.3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was 
taken  on-site  by  the  validation  team  for  processing.  The  contents  of  the 
magnetic  tape  were  loaded  directly  onto  the  computer. 


After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  inp)lementation. 


The  tests  were  compiled,  linked  and  executed  on  the  computer  system,  as 
appropriate.  The  results  were  captured  on  the  con^juter  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  iiip)lementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 

Switch  Effect 


-B  Produces  an  output  listing. 

-e  999  Sets  the  roaxinum  number  of  errors  to  999. 


-W  b,  -T  Suppresses  procedure  traceback  vdien  exceptions 

are  not  caught. 


Test  output,  conqpiler  and  linker  listings,  and  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by 
the  validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  ttsed  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  these  parameters  are  explained  in  [UG89].  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  meucimum  input-line  length,  which  is 
the  value  for  $MAX_IN_LEII — also  listed  here.  These  values  are  expressed 
here  as  Ada  string  aggregates,  where  "V”  represents  the  maximum  input-line 
length. 


Macro  Parameter 


Macro  Value 


$MAX  IN  LEN  255 


$BIG_ID1 

(1. 

$BIG_ID2 

(1. 

$BIG_ID3 

(1. 

$BIG_ID4 

(1. 

.V-1  ->  'A',  V  ->  '1') 

.V-1  ->  "AS  V  ->  '2') 

.V/2  ->  "A")  &  "3"  & 
(1..V-1-V/2  ->  "A") 

.V/2  ->  "A")  &  "4"  & 
(1..V-1-V/2  ->  "A") 


$BIG_INT_LIT 

$BIG_REAL_LIT 

$BIG_STRING1 

$BIGJSTRING2 

$BLANKS 


(l..y-3  ->  "0")  &  "298" 

(1..V-5  ->  "0")  &  "690.0" 

"""  &  (1..V/2  ->  "A")  & 

"""  &  (1..V-1-V/2  ->  "A")  &  "1"  & 
(1..V-20 


$MAX  LEM  ZMT  BASED  LITERAL 

”  "2:"  &  (l.,V-5  ->  "0")  &  "11:" 

$MAX_LEM_REAL  BASED  LITERAL 

"16:"  &  (1..V-7  ->  '0")  &  "F.E:" 


MACRO  PARAMETERS 


$MAX_STRING_LITERAL  &  (1..V-2  »>  'A')  & 


The  followin9  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 

Macro  Parameter  Macro  Value 


$ACC_SIZE 

32 

$ALIGNMENT 

4 

$COUNT_LAST 

2147483647 

$DEFAULT_MEM_SIZE 

2147483647 

$DEFAULT_STOR_UNlT 

8 

$DEFAULT_SyS_NAME 

HP9000_PA_RISC 

$DELTAJXX: 

2#1.0#e-31 

$ENTRy_AODRESS 

E2miy_ADDR 

$ENTRy_ADDRESSl 

ENTRy_ADDRl 

$ENTRy_AW)RESS2 

ENIRy_AM)R2 

$FIELD__LAST 

255 

$FILE  TERMINATOR 

/  r 

$FIXEDJ{AME 
$FLQAT_NANE 
$PORM_STRING 
$FQRM_STRING2 
$GREATER  THAN  DURATION 


NO_SUCH__FIXED_TYPE 

no_such__flqat_type 

fin 

"CANI«JT__RESlRICT_FILE_CAPACITy" 


100  000.00 


■  $GREATER_THANJDURATiaN  BASE  LAST 

Too_oiro_ooo.o 

$GREATER_THAN_FLQAT_BASE  LAST 

1.70141&I-38 

$(3ffiATER  THAN_FLCAT_SAFE  LARGE 

l.TFESe 
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$GREATER  THAN  SHORT  FLOAT  SAFE  LARGE 

~  1.0E308  “ 

$HIC2J_PRI0RITT  16 

$ILLEGAL_EXTERNAL_FILE_NAME1 

not_there//not_the  re/* '' 

$ILLEGAL_EXTERNAL_FILEJ1AME2 

not_there/no  t_the  re/no  t_the  re/ .  / .  /not_the  re/// 

$INAPPROPRIATE  LINE  LE34GTH 

-1 

$INAPPROPRIATE_PAaE_LENGTH 


-1 

$INCLUDE_PRAGMA1 

PRAGMA  INCLUDE  ( "A28006D1.TST" ) 

$INCLUDE_PRAGMA2 

PRAGMA  INCLUDE  ( "B28006D1  .ADA" ) 

$INTEGER_FIRST 

-2147483648 

$INTEGER__LAST 

2147483647 

$INTEGER_LAST_PLUS_1 

2147483648 

$INTERFACE_LANGUAGE 

C 

$LESS_THAN_DORATION 

-lOO^OOO.O 

$LESS  THAN  DURATION  BASE  FIRST 

”  ”  “  -iiyo_ooo_ooo.o 

$LINE_TERHINATOR 

f  9 

$LOW_PRIORITy 

1 

$HACHINE  CODE  STATEIlEin' 

NULL; 

$MACHINE_CODEjrePE 

NO_SUCH_TYPE 

$HANTISSA_DOC 

31 

$HAX_DIGITS 

15 

$MAX_INT 

2147483647 

$MAX_INT_PLUS_1 

2147483648 

$MIN_INT 

-2147483648 

$NAHE 


SHORT  SHORT  INTEGER 
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$NAME_LIST 

HP9000_PA_RISC 

$NAME_SPECIFICATICN1 

/ACVC/lnnt/root5/notrace/Test/ACVClB/RuivX2120A 

$NAME_SPECIFICATICN2 

/^VC:VC/tant/root5/hotrace/Test/ACVClB/RuiVX2120B 

$NAME_SPECIFICATICN3 

/ACVC/tant/root5/hotrace/rest/ACVClB/Run/X3114A 

$NBG_BASEp_INT 

16#FF_FF_FF_FD# 

$NEW_MEM_SIZE 

1048576 

$NEW_STOR_UNIT 

8 

$NEM_SYS_NAME 

HP9000_PA_RISC 

$PAGE_TERMINATOR 

ASCII. FF 

$RECORD_DEFINITIC]N 

RECORD  NULL;  END  RECORD; 

$RECORD_NAME 

NO_SUCH_MACHINE_CODE_TYPE 

$TASK_SIZE 

32 

$TASK_STORAGE_SIZE 

32768 

$TICK 

0.010 

$\«^riable_aooress 

VARIABLE_AIX>R; 

$VARIABLE_ADDRESS1 

VARIABLE_ADDR1; 

$VARIABLE_ADDRESS2 

VARIABLE_ADDR2 ; 

$YOOR_PRAGMA 

EXPORTJOBJECT 
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Hie  co^iler  opticas  of  this  Ada  inplementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer,  unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  con^iler  documentation  and 
not  to  this  report. 
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NAME 

ada  -  Ada  con;>iler 

snropsis 

ada  [options]  [files]  libraryname 
Remarks: 

This  command  requires  installation  of  optional  Ada  software 

(not  inclxided  with  the  standard  HP-UX  operating  system) 

before  it  can  be  used. 

DESCRIPTIGM 

a^  is  the  HP-UX  Ada  compiler.  It  accepts  several  types  of 

file  arguments: 

(1)  Arguments  whose  names  end  with  .ad?,  where  ?  is  any 
single  alphanumeric  character,  are  taken  to  be  Ada 
source  files. 

(2)  The  libraryname  argument  names  an  Ada  library  that  must 
have  been  previously  created  using  the  ada.mklib(l) 
command.  An  Ada  library  is  an  HP-UX  directory 
containing  files  that  are  used  by  the  various 
CQiq»nents  of  the  Ada  ccopilation  system.  There  is  no 
required  or  standard  suffix  on  the  name  of  an  Ada 
library. 

The  named  source  files  are  compiled  and  each 
successfully  coopiled  unit  is  placed  in  the  specified 
Ada  library  by  the  conpiler.  When  binding,  or  binding 
and  linking,  information  is  extracted  from  the  Ada 
library  to  perform  the  bind  and/or  link  operation.  The 
Ada  library  must  always  be  specified. 

TO  ensure  internal  data  structure  integrity  of  the  Ada 
libraries,  libraries  are  locked  for  the  duration  of  any 
operations  being  performed  on  them.  £>uring 
compilation,  libraryname  is  normally  locked  for 
updating,  arxl  other  Ada  libraries  can  be  locked  for 
reading.  During  binding/linking,  Ada  libraries  are 
only  locked  for  reading. 

If  a<to  cannot  obtain  a  lock  after  a  suitable  number  of 
retries,  it  displays  an  informational  message  and 
terminates. 

Users  are  strongly  discouraged  from  placing  any 
additional  files  in  Ada  library  directories.  User 
files  in  Ada  libraries  are  subject  to  damage  by,  or 
mi^t  interfere  with,  proper  operation  of  a^  and 
related  tools. 

(3)  All  other  file  arguments,  inclixling  those  vdiose  names 
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end  with  .o  or  .a  are  passed  on  to  the  linker  M(l)  to 
be  linked  into  the  final  program.  It  is  not  possible 
to  link-only  with  the  ada(l)  command. 

(4)  Although  shown  in  the  preferred  order  above,  options, 
files,  and  libraryname  arguments  can  appear  in  any 
order. 

Environment  Variables 

Ihe  environment  variable  ADAJPAIH  is  associated  with  all 
con^nents  of  the  Ada  conpilation  system.  It  must  be  set 
properly  and  exported  before  any  component  of  the  Ada 
coopilation  system  (including  ada)  can  be  used. 

Normally  this  variable  is  defined  and  set  in  the  system-wide 
shell  startup  files  /etc/profile  (for  sh(l)  and  ksh(l) )  and 
/etc/csh. login  (for  csh(l) ) .  However,  it  can  be  set  by  a 
user,  either  interactively  or  in  a  personal  shell  startup 
file,  .profile  (for  ^(1)  and  ksh( 1 ) )  or  .cshrc  (for 
csh( 1 ) ) . 

ADA  PATH  must  contain  the  path  name  of  the  directory  in 
v^Bi  the  Ada  conpiler  cooponents  have  been  installed. 

The  value  of  this  variable  must  be  a  rooted  directory  (that 
is,  it  must  begin  with  a  /)  and  the  directory  specification 
must  not  end  with  a  /. 

ADAOPTS 

The  environment  variable  ADAOPTS  can  be  used  to  supply 
commonly  used  (or  default)  arguments  to  ada.  ADAOPTS  is 
associated  directly  with  ada,  and  is  not  used  by  any  other 
conponent  of  the  Ada  conpilation  system. 

Arguments  can  be  pas^  to  ada  throu^  the  ADAOPTS 
environment  variable,  as  well  as  on  the  command  line. 
ada(l)  picks  up  the  value  of  ADAOPTS  and  places  its  contents 
before  any  arguments  on  the  command  line.  For  exanple  (in 
sh(l)  notation), 

$  ADAOPTS-"-v  -e  10" 

$  export  ADAOPTS 
$  ada  -L  source. ada  test. lib 

is  equivalent  to 

$  ada  -V  -e  10  -L  source. ada  test. lib 
Compiler  Options 

The  following  options  are  recognized: 

-a  string  Store  the  supplied  annotation  string  in  the 
library  with  the  cmpilation  unit.  This 
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String  can  later  be  displayed  by  the  unit 
manager,  itie  maximum  leng^  of  this  string 
is  80  characters.  The  default  is  no  string. 

-b  Display  abbreviated  conpiler  error  messages 

(default  is  to  display  the  long  forms). 

-c  Suppress  link  phase  and,  if  binding  occurred, 

preserve  the  object  file  produced  ^  the 
binder.  This  option  only  takes  effect  if 
linking  vrould  normally  occur.  Linking 
normally  occurs  vhen  binding  has  been 
requested. 

Use  of  this  option  caxjses  an  informational 
message  to  be  displayed  on  standard  error 
indicating  the  format  of  the  ld(l)  command 
that  should  be  used  to  link  tEe  program.  It 
is  recommended  that  the  user  su^ly 
additional  object  (.o)  and  archive  (.a)  files 
and  additional  library  search  paths  (-lx) 
only  in  the  places  specified  ty  the 
informational  message. 

If  the  -c  option  is  given  along  with  the  -d 
or  -0  option,  the  binder  must  assume  the  name 
for  the  eventual  executable  file,  in  order  to 
determine  vhat  to  name  the  debug^rofiling 
information  file  (see  -d  azxl  -D).  If  no  -o 
option  is  given,  the  debug/profiling 
information  file  will  be  named  a.out.cui,  and 
you  must  make  sure  the  eventual  executable 
file  is  named  a. out.  If  a  -o  outfile  option 
is  given,  the  debug/profiling  information 
file  will  be  named  outfile. cui,  and  you  must 
make  sure  the  eventual  executable  file  is 
named  outfile.  If  the  executable  is  not 
named  as  expected,  neither  ada.probe(l)  nor 
ada.txmed)  will  work  correctly. 

When  Id  is  later  used  to  actually  link  the 
program,  the  following  conditions  must  be 
met: 

1.  The  .o  file  generated  by  the  binder 
must  be  specified  before  any  HP-UX 
archive  is  specified  (either 
explicitly  or  with  -1 ) . 

2.  If  -Ic  is  specified  >hen  linking,  any 
.o  file  containing  code  that  uses 
stdioQS)  routines  must  be  specified 
before  -Ic  is  specified. 
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Catise  the  compiler  to  store  additional 
infomation  in  the  Ada  library  for  the  mits 
being  compiled  for  use  by  the  Ada  debugger 
( see  ada. probe ( 1 ) )  or  Ada  profiler  ( see 
ada.tune(l) ) .  Only  information  required  for 
debugging  or  profiling  is  saved;  the  source 
is  not  saved  (see  -D). 

Cause  the  binder  to  produce  a  debug/profiling 
information  file  for  the  program  being  bound 
so  that  the  resulting  program  can  be 
manipulated  by  the  Ada  debugger.  (Note:  if 
you  intend  to  \ise  the  Ada  profiler  you  should 
\jse  the  binder  option  -w  b,-p  instead  of 
using  -d  at  bind  time.)  The  binder  will 
produce  a  debug/profiling  information  file 
named  a.out.cui  (unless  -c  is  used  to  specify 
an  alternate  name).  If  the  debug  information 
file  name  would  be  truncated  by  the  file 
system  on  which  it  would  be  created,  an  error 
is  reported. 

Only  sources  conpiled  with  the  -d  or  -D 
option  contribute  information  to  the 
debug/profiling  information  file  produced  by 
the  binder.  Ihe  default  is  not  to  produce 
the  debug/profiling  information  (see  the  Ada 
Tools  Maj^l  for  more  details) .  See  -c  for 
information  on  the  enteraction  between  the 
-o,  -d,  -0,  and  -c  options. 

See  the  WARNINGS  section  for  information 
regarding  debugging  of  optimized  programs. 

St(p  coopilation  after  nrm  errors  (legal 
range  0.. 32767,  default  50). 

Cause  any  pending  or  existing  instantiations 
of  generic  bodies  in  this  Ada  library,  v^ose 
actual  generic  bodies  have  been  compiled  or 
recompiled  in  another  Ada  library,  to  be 
ccnpiled  (or  reconpiled)  in  this  Ada  library. 

This  option  is  treated  as  a  special  "source" 
file  arxi  the  cospilation  is  performed  when 
the  option  is  encountered  among  the  names  of 
any  actual  source  files. 

Any  pending  or  existing  instantiations  in  the 
same  Ada  library  into  which  the  actual 
generic  body  is  compiled  (or  reconpiled),  do 
not  need  this  optim.  Such  pending  or 
existing  instantiations  are  automatically 
compiled  (or  recoopiled)  when  the  actual 
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-k 


-lx 


nnn 


-n 


-o  outfile 


-<3 


generic  body  is  compiled  into  the  seune  Ada 
library. 

Warning:  Compilation  (or  recompilation)  of 
instantiations  either  automatically  or  by 
using  this  option  only  affects  instantiations 
stor^  as  separate  units  in  the  Ada  library 
(see  -u).  Existing  instantiations  which  are 
"in-line"  in  another  unit  are  not 
automatically  con^iled  or  recompiled  by  using 
this  option.  IMits  containing  such 
instantiations  must  be  explicitly  recompiled 
by  the  user  if  the  actxial  generic  body  is 
reconciled. 

Cause  the  conciler  to  save  an  internal 
representation  of  the  source  in  the  Ada 
library  for  use  by  the  Ada  cross  referencer 
ada.xref(l) .  By  default,  the  internal 
representation  is  not  saved. 

Caiise  the  linker  to  search  the  HP-UX  library 
named  either  /lib/libx.a  (tried  first)  or 
/\isr/lib/lit«.a  (see  Td(l) ) . 

Itie  supplied  niimber  is  the  size  in  Kbytes  to 
be  allocated  at  compile  time  to  manipulate 
library  information.  The  range  is  500  to 
32767.  The  default  is  500.  The  default  size 
should  work  in  almost  all  cases.  In  some 
extreme  cases  involving  very  large  programs, 
increasing  this  value  will  improve 
compilation  time. 

Cause  the  output  file  from  the  linker  to  be 
marked  as  shareable  (see  -N).  Do  not  use  the 
option  -n  when  also  profiling  with  the  option 
-W  b,-p.  For  details  refer  to  chatr(l)  and 
ld(l). 

Name  the  output  file  from  the  linker  outfile 
instead  of  a. out.  In  addition,  if  used  with 
the  -c  option,  name  the  object  file  output  by 
the  binder  outfile. o  instead  of  a.out.o.  If 
debugging  is  enabled  (with  -d  or  -D),  name 
the  debug  information  file  output  by  the 
binder  outfile. cui  instead  of  a.out.cui. 

If  -c  is  not  specified,  the  temporary  object 
files  used  in  the  link  operation  are  deleted, 
\Avether  or  not  the  link  succeeded. 

Caxise  the  output  file  from  the  linker  to  be 
marked  as  demeuxi  loadable  (see  -Q).  For 
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details  refer  to  chatr( 1 )  and  ld( 1 ) . 

-r  nnn  Set  listing  line  length  to  nnn  (legal  range 

60.. 255,  defaxilt  79).  This  option  applies  to 
the  listing  produced  by  both  the  coiopiler  and 
the  binder  (see  -B,  -L,  and  -W  b,-L). 

-s  Ca\ise  the  output  of  the  linker  to  be  stripped 

of  symbol  table  information  (see  ^(1)  and 
strip(l)). 

Use  of  this  option  prevents  ada.probe(l)  and 
ada. tuned)  from  functioning  correctly. 

-t  c,name  Substitute  or  insert  stjbprocess  c  with  name 
\diere  c  is  one  or  more  of  a  set  of 
identifiers  indicating  the  stjbprocess(es) . 
This  option  works  in  two  modes:  1)  if  c  is  a 
single  identifier,  name  represents  the  full 
path  name  of  the  new  svibprocess;  2)  if  c  is  a 
set  of  (more  than  one)  identifiers,  n^ 
represents  a  prefix  to  which  the  standard 
suffixes  are  concatenated  to  construct  the 
full  path  name  of  the  new  sxjt^rocesses. 

The  possible  values  of  c  are  the  following: 

b  binder  (standard  suffix  is  adabind) 
c  compiler  (standard  suffix  is  adaconp) 

7  same  as  c 

T  linker  (standard  suffix  is  ^) 

-u  Cause  instantiations  of  generic  program  unit 

bodies  to  be  stored  as  separate  units  in  the 
Ada  library  (see  -i). 

If  -u  is  not  specified  and  the  actual  generic 
body  has  already  been  ccmpiled  vdien  an 
instantiation  of  the  body  is  compiled,  the 
body  generated  by  the  instantiation  is  stored 
"in-line"  in  the  same  unit  as  its 
declaration. 

If  -u  is  specified  or  the  actual  generic  body 
has  not  already  been  compiled  vhen  an 
instantiation  of  the  body  is  compiled,  the 
body  generated  by  the  instantiation  is  stored 
as  a  separate  unit  in  the  Ada  library. 

The  -u  option  may  be  needed  if  a  large  number 
of  generic  instantiations  within  a  given  unit 
result  in  the  overflow  of  a  compiler  internal 
table. 
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Specifying  -u  reduces  the  amount  of  table 
space  needed,  permitting  the  compiler  to 
complete.  However  it  also  increases  the 
number  of  units  used  within  the  Ada  library, 
and  also  introduces  a  small  amount  of 
overhead  at  execution  time  in  units  v^ch 
instantiate  generics. 

-V  Enable  verbose  mode,  producing  a  step-by-step 

description  of  the  compilation,  binding,  and 
linking  process  on  standard  error. 

-w  Stqppress  warning  messages. 

-X  Perform  syntactic  checking  only.  The 

librarynane  argument  must  be  supplied, 
although  the  Ai^  library  is  not  modified  (see 
-X  and  -G) . 

-B  Catises  the  compiler  to  produce  a  compilation 

listing,  suppressing  page  headers  and  the 
error  summary  at  the  end  of  the  compilation 
listing.  This  is  useful  for  avoiding 
mismatches  caused  by  page  headers  when 
comparing  a  compilation  listing  with  a 
previous  compilation  listing  of  the  same 
program.  This  option  cannot  be  specified  in 
conjunction  with  the  -L  option. 

-C  S\jppress  njntime  checks  except  for  stack 

overflow.  Use  of  this  option  may  result  in 
erroneous  (in  the  Ada  sense)  program 
behavior.  In  addition,  some  checks  (such  as 
those  automatically  provided  by  hardware) 
might  not  be  suppressed  (see  -R). 

If  a  generic  body,  or  a  procedure  or  function 
that  may  be  included  "inline"  (see  the  +0  i 
and  -I  options),  is  compiled  with  this  option 
in  effect,  this  option  setting  is 
"remembered".  Vihen  the  generic  is 
instantiated,  or  the  procedure  or  function  is 
included  "inline",  the  compiler  will  produce 
code  for  that  instantiation  or  inlining  that 
is  consistent  with  the  "remembered"  option 
again  being  in  effect  (i.e.  the  runtime 
checking  level  specified  to  the  compiler 
which  is  compiling  the  instatiation  or 
inlined  procedure  or  function  is  ignored  for 
the  duration  of  the  instantiation  or  inlining 
and  the  runtime  checking  level  specified  vdien 
the  generic  body  or  orignal  procedure  or 
function  was  compiled  is  used  instead) . 
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See  the  Users  Guide  for  more  information. 

Cause  the  conpiler  to  store  additional 
information  in  the  Ada  library  for  the  units 
being  conpiled,  for  use  by  the  Ada  debugger 
(see  ada.probe(l) )  or  Ada  profiler  (see 
ada.tune(l) ) .  In  addition  to  saving 
information  required  for  debugging  and 
profiling,  an  internal  representation  of  the 
actual  source  is  saved.  This  permits 
accurate  source  level  debugging  and  profiling 
at  the  expense  of  a  larger  Ada  libra^  if  the 
actual  source  file  changes  after  it  is 
conpiled  (see  -d).  By  defa\ilt,  neither 
debug/profiling  information  nor  source 
information  is  stored. 

Cause  the  binder  to  produce  a  debug/profiling 
information  file  for  the  program  being  bound 
so  that  the  resulting  program  can  be 
manipulated  by  the  Ada  debugger  (Note:  if  you 
intend  to  use  the  Ada  profiler  you  should  use 
the  binder  option  -W  b,-p  instead  of  using  -D 
at  bind  time),  ihe  binder  wil  produce  a 
debug  profiling  information  file  named 
a.out.cui  (unless  -o  is  used  to  specify  an 
alternate  name).  If  the  debug  information 
file  name  would  be  tnjncated  by  the  file 
system  on  which  it  is  to  be  created,  an  error 
is  reported. 

Only  sources  cospiled  with  the  -d  or  -D 
option  contribute  information  to  the 
debug/profiling  information  file  produced  by 
the  binder.  Ihe  default  is  not  to  produce 
the  debug/profiling  information  (see  the  Ada 
Tools  Manual  for  more  details).  See  -c  for 
information  on  the  interaction  between  the 
-o,  -d,  -D,  and  -c  options. 

See  the  WARNINGS  section  for  information 
regarding  debugging  of  optimized  programs. 

Generate  code  but  do  not  \jpdate  the  library. 
Hiis  is  primarily  intended  to  allow  one  to 
get  an  assembly  listing  (with  >S)  without 
changing  the  library.  Ihe  libraryname 
argument  must  be  supplied,  although  the  Ada 
library  is  not  modified  (see  -x  and  -X). 

Causes  the  conpiler  to  produce  informational 
messages  of  interest  to  users  of  the 
INTERRUPT_MANAGER  package  (v^ich  is  described 
by  the  appropriate  Reference  Manual  for  the 
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Ada  Proqramning  Language,  Appendix  F) .  Three 
types  of  messages  are  produced: 

1.  information  that  an  Ada  runtime  system 
routine  will  be  called  from  the 
generated  code  for  the  indicated 
construct.  The  name  of  the  Ada 
nmtime  system  routine  will  be 
indicated. 

2.  Information  that  an  Ada  type  sr^iport 
sul^rogram  (TSS)  will  be  called  from 
the  generated  code  for  the  indicated 
construct.  The  name  of  the  Ada  type 
that  the  TSS  supports  will  be 
indicated. 

3.  Information  indicating  the  size  in 
bytes  of  the  parameter  block,  for  a 
task  entry  for  which  an  address  clause 
has  been  specified. 

The  first  two  kinds  of  messages  are  of 
interest  v^en  compiling  the  bodies  of  signal 
handlers  for  xise  with  the  iNTERRUFT_nANAGER 
package.  The  third  kind  of  message*~is  of 
interest  vhen  compiling  the  specifications  of 
tasks  vhich  contain  entries  v^ich  will  be 
called  by  the  INTERRUPTJIANAGER  package. 

If  you  generate  a  conplete  compiler  listing 
witii  the  -B  or  -L  options,  the  informational 
messages  appear  in  the  compiler  listing  at 
the  appropriate  source  lines.  If  you  do  not 
generate  a  complete  compiler  listing,  only 
the  source  lines  that  apply  to  the 
informational  message  appear  with  the 
informational  message.  The  information 
nonmally  produced  -H  will  be  suppressed  if 
-b  is  also  specified. 

-I  Suppress  all  inlining.  NO  procedures  or 

functions  are  expand^  inline  and  pragma 
inline  is  ignored.  This  also  prevents  units 
compiled  in  the  future  (without  this  option 
in  effect)  from  inlining  any  units  compiled 
with  this  option  in  effect. 

-L  Write  a  program  listing  with  error 

diagnostics  to  standard  output.  This  option 
cannot  be  specified  in  conjunction  with  the 
-B  option. 
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Invoke  the  binder  after  all  source  files 
named  in  the  command  line  (if  any)  have  been 
successfully  conpiled.  The  argument  main 
specifies  the  entry  point  of  the  Ada  program; 
main  must  be  the  name  of  a  parameterless 
Ada-library-level  procedure. 

The  library-level  procedure  main  must  have 
been  successfully  conpiled  into  (or  linked 
into)  the  named  Ada  library,  either  by  this 
invocation  of  ada  or  by  a  previous  invocation 
of  ada  (or  ada.umgr(l) ). 

The  binder  produces  an  object  file  named 
a.out.o  (unless  -o  is  used  to  specify  an 
alternate  name),  only  if  the  option  -c  is 
also  specified.  The  object  file  produced  by 
the  binder  is  deleted  imless  the  option  -c  is 
specified.  Note  that  the  alternate  name  is 
truncated,  if  necessary,  prior  to  appending 
.o. 

Catise  the  output  file  from  the  linker  to  be 
marked  as  unshareable  (see  -n).  For  details 
refer  to  chatr(l)  and  ld(l) . 

Invoke  the  optimizer  with  full  optimizations. 
See  the  description  of  40  under  the 
DEPENDENCIES  section  for  more  information. 

See  the  WARNINGS  section  for  information 
regarding  debugging  of  optimized  programs. 

Set  listing  page  length  to  nnn  lines  (legal 
range  10 . . 32767  or  0  to  indicate  no  page 
breaks7  default  66}.  This  length  is  the 
total  number  of  lines  listed  per  listing 
page.  It  includes  the  heading,  header  and 
trailer  blank  lines,  listed  program  lines, 
and  error  message  lines.  This  option  applies 
to  the  listing  produced  by  both  the  conpiler 
and  the  binder  (see  -L  and  -W  b,-L). 

Cause  the  output  file  from  the  linker  to  be 
marked  as  not  demand-loadable  (see  -q).  For 
details  refer  to  chatr(  1 )  and  ^(  1 ) . 

Suppress  all  run-time  checks.  However,  some 
checks  (such  as  those  automatically  provided 
hardware)  might  not  be  suppressed,  use  of 
this  option  may  result  in  erroneous  (in  the 
Ada  sense )  program  behavior  ( see  -C  ) . 

If  a  generic  body,  or  a  procedure  or  function 
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that  may  be  included  "inline"  (see  the  40  i 
and  -I  options),  is  compiled  with  this  option 
in  effect,  this  option  setting  is 
"remembered",  when  the  generic  is 
instantiated,  or  the  procedure  or  function  is 
included  "inline",  the  conpiler  will  produce 
code  for  that  instantiation  or  inlining  that 
is  consistent  with  the  "remembered"  option 
again  being  in  effect  (i.e.  the  runtime 
checking  level  specified  to  the  compiler 
which  is  conpiling  the  instatiation  or 
inlined  procedure  or  function  is  ignored  for 
the  duration  of  the  instantiation  or  inlining 
and  the  nintime  checking  level  specified  v^en 
the  generic  body  or  orignal  procedure  or 
function  was  conpiled  is  used  instead) . 

-S  Write  an  assembly  listing  of  the  code 

generated  to  standard  output.  This  output  is 
not  in  a  form  suitable  for  processing  with 
as(l) . 

-W  c,argl[  ,arq2, . . .  ,ar^] 

Cause  arql  through  arqN  to  be  handed  off  to 
subprocess  c.  Each  arqi  is  of  the  form 
-arqoptiont ,aryralue] ,  where  arqoption  is  the 
name  of  an  option  recognized  by  the 
subprocess  and  arqvalue  is  a  separate 
argument  to  argo^ion  where  necessary.  The 
vedues  that  c  can  assume  are  those  listed 
under  the  -t  option  as  well  as  d  (driver 
program) . 

To  pass  the  -r  (preserve  relocation 
information)  option  to  the  linker,  use: 

-W  1,-r 


The  following  sends  the  options  -m  10  -s  2  to 
the  binder: 

-W  b,Hii,10,-s,2 

Note  that  all  the  binder  options  can  be 
svqplied  with  one  -W,  (more  than  one  -W  can 
also  be  used)  and  that  any  embedded  spaces 
must  be  replaced  with  commas.  Note  that  -w  b 
is  the  only  way  to  specify  binder  options. 

The  -W  d  option  specification  allows 
additional  inplementation-specific  options  to 
be  recognized  and  passed  through  the  conpiler 
driver  to  the  appropriate  subprocess.  For 
exanple. 
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-W  d,-0,eo 

sends  the  option  -o  eo  to  the  driver,  vhich 
sends  it  to  the  conpiler  so  that  the  e  and  o 
optimizations  are  performed.  Furthermore,  a 
shorthand  notation  for  this  mechanism  can  be 
used  by  inserting  +  in  front  of  the  option  as 
follows: 

40  eo 

This  is  equivalent  to  -w  d,-0,eo.  Note  that 
for  sinplicity  this  shorthwd  is  applied  to 
each  in{)lementation-specific  option 
individ^ly,  and  that  the  arq^ue  (if  any) 
is  separated  from  the  shorthand  argoption 
with  white  space  instead  of  a  comma. 

■X  Perform  syntactic  and  semantic  checking.  The 

libraryname  argument  must  be  supplied, 
although  the  Ai^  library  is  not  modified  (see 
-X  and  -G  ). 


Binder  Options 

The  following  options  can  be  passed  to  the  binder  using 
-V  b, . . . : 


-W  b,-b 


-W  b,-k 


At  execution  time,  the  Ada  STANnARD_INPUT  and 
STANDARD  OUTPUT  files  will  block  if  data  is 
not  avaiXable  .(STANDARD_INFUT)  or  if  data 
cannot  currently  be  written  (STANDARD  OUTPUT) 
or  if  the  data  to  be  read  or  written  Ties  in 
a  locked  region.  All  tasks  will  be  suspended 
when  an  I/O  operation  on  one  of  these 
standard  files  blocks.  This  option  is  the 
default  if  the  program  contains  no  tasks  (see 
-W  b,-B  for  more  details). 

Keep  ;jncalled  sxibprograms  \idien  binding.  The 
default  is  to  remove  them. 


-W  b,-4n,nnn  Series  300/400:  Set  the  initial  program  stack 
size  to  nnn  units  of  1024  bytes  (legal  range 
1.. 32767,  defaxilt  10  units  -  10  *  1024  bytes 
-  10240  bytes). 

Series  600/700/800:  Set  the  maximum  stack 
limit  of  the  program  stack  to  units  of 
1024  bytes  (legal  range  512..3I7F7,  defaults 
to  a  systenHdefined  limit). 

-W  b,-p  Cause  the  binder  to  link  the  program  in  the 

special  manner  required  by  ada.t\me(l)  and  to 
place  additional  information  in  the 
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debug/profiling  information  file  for  use 
ada.t\ine(l).  Note  that  neither  -d  nor  -D 
needs  to  be  specified  \dien  binding  if  this 
qption  is  specified,  as  this  option  causes 
the  same  binder  action  as  -d  a^  -D  plus  the 
additional  actions  noted  above. 

If  you  specify  the  -c  option  vAien  binding, 
you  will  need  to  specify  special  options  and 
object  files  when  linking  with  ]^(1)  in  order 
for  ada.tune(l)  to  function  correctly.  When 
you  specify  -c,  the  ld(l)  command  you  need  to 
use  will  be  displaye3~as  an  informational 
message  by  the  binder.  Consult  the  Ada  Tools 
Manual  for  your  in^lementation  for  further 
information. 

b,-s,nnn  Catise  round-robin  scheduling  to  be  used  for 
tasking  programs.  Set  the  time  slice  to  mn 
tens  of  milliseconds  (legal  range  1.. 32767  or 
0  to  turn  off  time  slicing).  By  default, 
round-robin  scheduling  is  enabled  with  a  time 
slice  of  1  second  (nnn  >  100). 

Hie  time  slice  granularity  is  specified  under 
the  DEPENDENCIES  section. 

-w  b,-t,nnn  Set  the  total  task  'ST0BAGE_S1ZE  to  nnn  units 
of  1024  bytes  for  each  task  \idiich  does  not 
have  a  length  clause. 

Cause  this  amount  of  space  to  be  allocated 
for  the  total  task  data  area  vAiich  includes 
both  the  task  stack  and  the  overhead  for  the 
Ada  runtime  system. 

Series  300/400:  The  Ada  runtime  system 
overhead  is  approximately  3600  l^es,  so  the 
minimum  usable  value  of  nnn  is  4.  The 
default  is  32  units,  equal  to  32  *  1024  bytes 
>  32768  bytes,  less  3600  bytes  leaves  29168 
t^es  for  the  task  stack. 

Series  600/700/800:  The  Ada  runtime  system 
overhead  is  approximately  5400  bytes,  so  the 
minimum  usable  value  of  nmi  is  6.  The 
default  is  32  units,  equal  to  32  *  1024  bytes 
•  32768  bytes,  less  5400  bytes  leaves  27368 
bytes  for  the  task  stack. 

If  insufficient  space  is  allocated  either 
TASKING_ERFOR  or  STDRAGE_ERROR  will  occur 
during  task  elaboration  or  activation. 
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-W  b,^ 
-W  b,-x 

-W  b,-B 


-W  b,-L 

-w  b,-s,t 


-W  b,-T 

Locks 
TO  ensure 


The  legal  range  is  1.. 32767  units. 

Sr^ress  warning  messages  from  the  binder. 

Perform  consistency  checks  without  producing 
an  object  file,  and  suppress  linking.  The 
-W  b,-L  option  can  be  used  to  obtain  binder 
listing  informatics  when  this  option  is 
specified  (see  -w  b,-L  below). 

At  execution  time,  the  Ada  STANDARD  INPUT  and 
STANDABDjOUTPUT  files  will  not  bloclc  if  data 
is  not  available  (STANDABD_INPUT)  or  if  data 
cannot  currently  be  written  (STANDARD  OUTPUT) 
or  if  the  data  to  be  read  or  written  Ties  in 
a  locked  region.  Ihe  task  attempting  the  I/O 
operation  that  cannot  currently  be  completed 
will  be  sxispended  (and  the  I/O  operation 
retried  later),  but  other  tasks  will  continue 
to  nm  as  appropriate.  This  option  is  the 
default  if  the  program  contains  tasks  (see 
-W  b,-b  for  more  details). 

Write  a  binder  listing  with  waming/error 
diagnostics  to  standard  error. 

Specifies  which  HP-UX  timer  should  be  used  to 
inclement  task  time-slicing.  If  time-slicing 
is  not  also  enabled,  this  option  has  no 
effect. 

The  argument  t  is  a  single  character  that 
specifies  whiBi  timer  to  xise.  The  legal 
values  of  t  and  their  meanings  are: 

a  or  ^ :  Use  the  timer  which  generates 
SIGALBH  for  time-slicing. 

2  or  P  :  Use  the  timer  which  generates 
SIGPROF  for  time-slicing. 

V  or  V  :  Use  the  timer  which  generates 
SIGVTALRH  for  time-slicing. 

The  default  is  to  use  the  timer  which 
generates  SIGVTALRH  for  time-slicing. 

Su^ress  procedure  traceback  in  response  to 
runtime  errors  and  unhandled  exceptions. 

This  also  causes  traceback  tables  to  be 
excluded  from  the  final  executable  file. 


the  integrity  of  their  internal  data  structures. 
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Ada  libraries  and  families  are  locked  for  the  duration  of 
operations  that  are  performed  on  them.  Normally  Ada 
families  are  locked  for  only  a  short  time  when  libraries 
within  them  are  manipulated.  However,  multiple  Ada 
libraries  might  need  to  be  locked  for  longer  periods  during 
a  single  operation.  If  more  than  one  library  is  locked,  ada 
places  an  exclxisive  lock  on  one  library  so  it  can  be 
u^xiated,  and  a  shared  lock  on  the  other(s)  so  that  they  can 
remain  open  for  read-only  purposes. 

An  Ada  family  or  library  locked  for  updating  cannot  be 
accessed  in  any  way  by  any  part  of  the  Ada  conpilation 
system  except  by  ^e  part  that  holds  the  lock.  An  Ada 
family  or  library  locked  for  reading  can  be  accessed  by  any 
part  of  the  Ada  conpilation  system  desiring  to  read  from  the 
Ada  family  or  library. 

If  a^  cannot  obtain  a  lock  after  a  sxiitable  nvanber  of 
retries,  it  displays  an  informational  message  and 
terminates. 

under  some  circumstances,  an  Ada  family  or  Ada  library  might 
be  locked,  but  the  locking  program(s)  might  have  terminated 
(for  exanple,  due  to  system  crash  or  network  failure).  If 
you  determine  that  the  Ada  family  or  Ada  library  is  locked 
but  should  not  be  locked,  you  can  remove  the  lock. 

Use  ada.unlock(l)  to  unlock  an  Ada  library  aix! 
a^.funlockd)  to  xinlock  an  Ada  family.  However,  unlocking 
should  be  done  with  care.  If  an  Ada  family  or  Ada  library 
is  actually  locked  by  a  tool,  unlocking  it  will  permit 
access  by  other  tools  that  might  find  the  contents  invalid 
or  that  might  damage  the  Ada  family  or  Ada  library. 

EXTERNAL  INFLUEHCES 

Intematiotial  Code  Set  Su{^rt 
Single-byte  character  code  sets  are  sxjpported  within  file 
names. 

DIAGNOSTICS 

Ihe  diagnostics  produced  by  ada  are  intended  to  be  self- 
explanatory.  Occasional  messages  might  be  produced  by  the 
linker. 

‘  If  a  program  listing  (-B  or  -L)  and/or  generated  code 
listing  (-S)  is  requested  from  the  conpiler,  this  listing  as 
well  as  coopiler  error  messages  are  written  to  standard 
output. 

If  neither  a  program  listing  nor  a  generated  code  listing  is 
requested  from  the  compiler,  erroneous  source  lines  and 
ccmpiler  error  messages  are  written  to  standard  error. 


B-16 


COMPILATION  SYSTEM  OPTIONS 


If  a  binder  listing  is  requested  from  the  binder  (with 
-W  b,-L),  the  binder  listing  as  well  as  binder  error 
messages  are  written  to  standard  error. 

If  a  binder  listing  is  not  requested  from  the  binder,  binder 
error  messages  are  written  to  standard  error. 

Errors  detected  during  coomand  line  processing  or  during 
scheduling  of  the  compiler,  binder,  or  linker,  are  written 
to  standard  error.  If  any  compiler,  biimler,  or  linker 
errors  occur,  ada  writes  a  one-line  sxmsnary  to  standard 
error  immediately  before  terminating. 

WARNINGS 

Options  not  recognized  by  ada  are  not  passed  on  to  the 
linker.  The  option  -W  l,arq  can  also  be  used  to  pass 
options  to  the  linker  explicitly. 

ada  does  not  generate  an  error  or  warning  if  both 
optimization  and  debugging  are  requested.  However, 
ada. probe  is  only  capable  of  limited  debugging  of  optimized 
code.  Certain  ada. probe  commands  may  give  misleading  or 
unexpected  results.  For  example,  object  values  may  be 
stored  in  registers;  therefore  the  vedue  displayed  from 
miemory  may  be  incorrect.  For  this  reason,  the  ability  to 
exaioine  or  modify  objects  and  expressions  may  be  impaired. 
Dead-code  elimination  or  code  motion  may  affect  single  step 
execution  or  prevent  breakpoints  from  being  set  on  specific 
source  lines. 

DEPENDENCIES 

Series  300/400 

The  compiler  option  -H  is  not  supported  on  the  Series 
300/400. 

The  binder  option  -W  b,^  behaves  differently  on  the 
Series  300/400  versus  the  Series  600/700/800.  See  the 
section  Binder  options  for  more  information. 

The  time  slice  granxdarity  for  round-robin  scheduling 
is  20  milliseconds. 

The  following  options  are  specific  to  the  Series 
300/400: 

•fO  what  Selectively  invoke  optimizations.  The  wfiat 
argument  must  be  specified,  and  indicates 
which  optimizations  should  be  performed. 
Note  that  the  option  -O  is  equivalent  to 
-K)  eioE. 

The  what  argument  can  be  a  combination  of 
the  letters  e,  i,  o,  p,  E,  and  P.  Either  e 
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or  p,  but  not  both,  can  be  specified. 
Siioiiarly,  either  E  or  P,  but  not  both,  can 
be  specified.  All  other  combinations  are 
permitted,  but  only  one  of  each  letter,  at 
most,  can  be  speciHed. 

e  Same  as  p  (below). 

i  Permit  procedures  and  functions 

not  declared  with  pragma  inline  to 
be  expanded  inline  at  the 
coopiler's  discretion.  Only 
procedures  and  functions  in  the 
current  source  file  are 
considered. 

Procedures  and  functions  declared 
with  pragma  inline  are  always 
considered  candidates  for  inline 
expansicm  unless  -I  is  specified; 
this  optimization  only  causes 
additional  procedures  and 
functions  to  be  considered. 

o  Peephole  optimizations  are 

performed  on  the  final  object 
code. 

p  Optimizations  are  performed  to 

remove  unnecessary  checks, 
optimize  loops,  a^  remove  dead 
code. 

E  Same  as  P  (below). 

P  Optimizations  are  performed  on 

common  s\:ibexpressions  and  register 
allocation. 

•fh  type  Bind/link  the  program  to  use  the  specified 
type  of  hardware  floating-point  assist  for 
user  code  floating-point  operations  (see 
•t-H).  The  two  types  currently  supported  are 

68881  (the  MC  6b881  math  coprocessor)  and 

68882  (the  HC  68882  math  coprocessor).  The 
code  generated  is  the  same  for  either  type. 
This  is  the  default  if  the  host  system 
provides  a  MC  68881  or  a  fTC  68882 
coprocessor.  This  option  is  ignored  if 
floating  point  operations  were  conf)iled 
inline  with  the  •i-i  type  option. 

'*’i  type  Compile  the  program  to  inline  the  specified 
type  of  hard^re  floating-point  assist  for 
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user  code  floating-point  operations  (see 
•fl).  The  two  types  currently  stq^rted  are 

68881  (the  HC  6B881  math  coprocessor)  and 

68882  (the  MC  68882  math  coprocessor).  The 
code  generated  is  the  same  for  either  type. 
This  is  the  default  if  the  host  system 
provides  a  MC  68881  or  a  MC  68882 
coprocessor.  Once  inlined  with  this 
option,  the  bind/linJc  options  -fh  type  and 
•fH  are  ignored. 

•fH  Bind/link  the  program  to  use  software 

floating-point  routines  for  user  code 
floating-point  operations  (see  +h).  This 
is  the  default  if  the  host  system  does  not 
provide  a  MC  68881  or  a  MC  68882 
coprocessor.  This  option  is  ignored  if 
floating  point  operations  were  compiled 
inline  with  the  -t-i  type  option. 

•fl  Coopile  the  program  to  maJce  caxls  to  a  math 

library  for  xiser  code  floating  point 
(^rations  (see  -fi).  The  -t-h  or  +H  options 
are  then  used  at  binct/link  time  to  specify 
vdiether  hardware  or  software  is  xised  for 
floating  point  operations.  This  is  the 
defaxilt  if  the  host  system  does  not  provide 
a  nc  68881  or  a  HC  68882  coprocessor. 

Unlike  other  Series  300/400  coopilers,  it  is  not 
possible  to  link-only  using  the  ada(l)  command.  If 
separate  linking  is  desired,  use  the  ^(1)  command. 

A  successful  bind  produces  a  (non-executable)  .o  file. 
The  .o  file  is  iwraudly  deleted  unless  the  option  -c  is 
specified. 

Series  600/700/800 

The  binder  option  -w  b,Hn  behaves  differently  on  the 
Series  300/400  versus  the  Series  600/700/800.  See  the 
section  Binder  Options  for  more  information. 

The  time  slice  granularity  for  round-robin  scheduling 
is  10  milliseconds. 

The  following  options  are  specific  to  the  Series 
600/700/800: 

•riiftarchitecture 

(^nerate  code  for  the  architecture 
specified,  architecture  is  required.  The 
default  code  generated  for  the  Series  800 
is  PA_RISC_1.0.  The  default  code  generated 
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for  the  Series  700  is  PA_RISC_1.1.  The 
default  code  generation  may  be  overriden 
using  the  AEAOPTS  environment  variable  or 
the  command  line  option  -t-DA.  Defined 
values  for  architecture  are: 

1.0  Precision  Architecture  RISC, 
version  1.0. 

1.1  Precision  Architecture  RISC, 
version  1.1. 

The  compiler  determines  the  target 
architecture  using  the  following 
precedence: 

1.  Command  line  specification  of  -i-EA. 

2.  Specification  of  -fCA  in  the  ADAOPTS 
environment  variable. 

3.  Ohe  default  as  mentioned  above. 


^^DSarchitecture 

Use  the  instruction  scheduler  tuned  to  the 
architecture  specified,  architecture  is 
required.  If  this  option  is  not  used,  the 
compiler  uses  the  instruction  scheduler  for 
the  architecture  on  v^ich  the  program  is 
coopiled.  Defined  values  for  architecture 
are: 

1.0  Precision  Architecture  RISC, 
version  1.0. 

1.1  Precision  Architecture  RISC, 

version  1.1,  general  scheduling 
for  the  series  700. 

1.1a  Scheduling  for  specific  models  of 
Precision  Architecture  RISC, 
version  1.1. 

40  what  Selectively  invoke  optimizations.  The  what 
argument  must  be  specified,  and  indicates 
\diich  optimizations  should  be  performed. 
Note  that  the  option  -O  is  equivalent  to 
40  eilE. 

The  what  argianent  can  be  a  combination  of 
the  letters  e,  i,  0,  1,  p,  E,  and  P. 

Either  e  or  p,  but  not  both,  can  be 
specified.  Similarly,  either  E  or  P,  but 
not  both,  can  be  specified.  Similarly, 
either  0  or  1,  but  not  both,  can  be 
specified.  All  other  ccmabinations  are 
permitted,  but  only  one  of  each  letter,  at 
most,  can  be  specified. 
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e  Same  as  p  (below). 

i  Permit  procedures  and  functions  not 
declared  with  pragma  inline  to  be 
expanded  in-line  at  the  coopiler's 
discretion.  Only  procedures  and 
functions  in  the  current  source 
file  are  considered. 

Procedures  and  functions  declared 
with  pragma  inline  are  always 
considered  candidates  for  inline 
expansion  unless  -I  is  specified; 
this  optimization  only  causes 
additional  procedures  and  functions 
to  be  considered. 

0  Hie  code  generator  performs  no 
optimizations. 

1  The  code  generator  performs  level  1 
optimizations. 

p  Optimizations  are  performed  to 

remove  unnecessary  checks,  optimize 
loops,  and  remove  dead  code. 

E  Same  as  P  (below). 

P  Optimizations  are  performed  on 

common  subexpressions  and  register 
allocation. 

•t-T  Su^ress  the  generation  of  traceback 

information  at  coopile  time.  In  addition 
to  suppressing  traceback  of  the  current 
conpilation  unit  at  run  time,  this  also 
reduces  the  size  of  the  object  file  in  the 
ada  library. 

Unlike  other  Series  600/700/800  compilers,  it  is  not 
possible  to  link-only  using  the  ada(l)  command.  If 
separate  linking  is  desired,  use  ld(l). 

A  successful  bind  produces  a  (non-executable)  .o  file. 
The  .o  file  is  normally  deleted  unless  the  option  -c  is 
specified. 


Aunm 

Ada  was  developed  HP  and  Alsys. 


FILES 

file. ad?  ii^t  file  (Ada  source  file), 

libraryname  user  Ada  library  (created  using 
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file.o 


a. out 
file.cui 

$AEA_FATH/ada 

$ADA_PA'l^adacoinp 

$ADA_PAllV^dabind 

$AnA~PAni/adajenvi  ron 

$ADA_PATl(/adaargu 

$AOA~PATEi/altemate 

$ADA_PA'ni/installation 

$AnA_PATH/]public 

$AnA_PAWerr_tpl 

$ADA_PATH/predef  1  ib 

$ADA_PAWlibada .  a 

$ADA_PA'ni/libada020  .a 

$ADA_PATIVlibada881 . a 

/lib/crtO.o 

/lib/libc.a 

/lib/lifam.a 


ada.mklibC  1 ) )  in  \^ich  compiled 
units  are  placed  by  a  successful 
conpilation  and  from  which  the 
binder  extracts  the  mits 
necessary  to  build  a  relocatable 
file  for  ld(l).  Tenporary  files 
generatedT^  the  compiler  are  also 
created  in  this  directory  and  are 
automatically  deleted  on 
successful  conpletion.  Users  are 
strongly  discouraged  from  placing 
any  additional  files  in  Ada 
library  directories.  User  files 
in  Ada  libraries  are  subject  to 
damage  by,  or  may  interfere  with 
proper  operation  of  ada  and 
related  tools. 

binder-generated  object  file  or 
user-specified  object  file 
relocated  at  link  time, 
linked  executable  output  file, 
binder-generated  debug/profiling 
information  file. 

Ada  ccopilation  driver  program. 

Ada  compiler. 

Ada  binder. 

Ada  environment  description  file. 
Ada  argument  formatter. 

Ada  pr^efined  library,  sequential 
version. 

Ada  installation  family. 

Ada  public  family. 

Ada  compile r/binder  error  message 
files. 

Ada  predefined  library,  tasking 
version. 

Ada  run-time  HP-UX  library. 

Series  600/700/800  only. 

Ada  run-time  HP-UX  library 
(HC68020).  Series  300/400  only. 
Ada  run-time  HP-UX  library 
(MC68881).  Series  300/400  only. 

C  run-time  startup. 

HP-UX  C  library. 

HP-UX  math  library 


SEE  ALSO 

ada.cplib(l) , 

ada.l^r(l) , 

ada.lsfam(l), 

ada.mklib(l), 

ada.mvfamd), 

ada.rmfam(l), 

ada.nnlib(l). 


ada.fmgr(l),  ada.format(l) ,  ada.funlock(l) , 
ada.lslib(l),  ada.make(l),  ada.mkfamd), 
ada.mvlibd),  ada. probed),  ada.protectd) , 
ada. tuned),  ada.umgrd),  ada.unlockd) , 
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ada.xref(l), 

Ada  User^s  Guide  for  Ada/300, 

Ada  User's  Guide  —  HP  9000  Series  600/700/800, 

Ada  Tools  Manual  for  Ada/300, 

Ada  Tools  Manual  —  HP  9000  Series  600/700/800 , 

Reference  Manual  for  the  Ada  Programminq  Language 
(ANSI/MIL-STD-IBIEaT, 

Reference  Myiual  for  ^e  Ada  Programming  Language, 
^^ndix  F  for  Ada/300, 

Reference  Manual  fir  the  Ada  Progranming  Language, 
AE^ndix”F  —  HP  9000  Series  600/^00/806. 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  inplementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  aj^ndix  are  to  linker  documentation  2uid  not 
to  this  report. 
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NAME 

Id  -  link  editor 

SYNOPSIS 

Id  [-bdmnqrstvxzENQZ]  [-a  search]  ...  [-e  epsym]  [-h 

symboll  ...  [-o  outfile]  [-u  sy^l]  ...  [ -A  name]  [-B 

bind]  [-L  dir]  . . .  [-R  offset]  [-V  num]  [-X  num]  [-lx 

I  file]  ... 

DESCRIPTIGN 

Id  takes  one  or  more  object  files  or  libraries  as  input  and 
combines  them  to  produce  a  single  (usually  executable)  file. 
In  doing  so  it  resolves  references  to  external  symbols, 
assigns  final  addresses  to  procedures  and  variables,  revises 
code  and  data  to  reflect  new  addresses  (a  process  called 
"relocation"),  and  updates  symbolic  debug  information  (when 
present  in  the  file).  By  default,  ^  produces  an  executable 
file  that  can  be  run  by  the  HP-UX  loader  exec(2) . 
Alternatively,  the  linker  can  generate  a  relocatable  file 
that  is  suitable  for  further  processing  (see  -r 

below).  It  can  also  generate  a  shared  library  (see  -b 
below).  Ihe  linker  marks  the  output  file  non-executable  if 
any  unresolved  external  references  remain.  Id  may  or  may 
not  generate  an  output  file  if  ai^  other  errors  occur  during 
its  operation;  see  DEPENDENCIES.  Id  recognizes  three  kinds 
of  input  files:  object  files  creatiS  by  the  con^ilers, 
assembler,  or  linker  (also  known  as  ''.o"  files),  shared 
libraries  created  the  linker,  and  archives  of  object 
files  (called  archive  libraries).  An  archive  library 
contains  an  index  of  all  the  extemally-visible  symbols  from 
its  coofxment  object  files.  (The  archiver  command  ar(l) 
creates  and  maintains  this  index. )  Id  uses  this  table  to 
resolve  references  to  external  symb^s. 

Id  processes  files  in  the  same  order  as  they  appear  on  the 
ccmnmnd  line.  It  includes  code  and  data  from  an  archive 
library  element  if  and  only  if  that  object  module  provides  a 
definition  for  a  currently  imresolved  reference  within  the 
user's  program.  It  is  common  practice  to  list  libraries 
following  the  names  of  all  single  object  files  on  the 
command  line. 

Code  from  shared  libraries  is  never  copied  into  an 
‘  executable  program,  and  data  is  copied  only  if  referenced 
directly  by  the  program.  Uie  dynamic  loader  /lib/dld.sl  is 
invoked  at  startiq)  time  by  /lib/crtO.o  if  a  program  uses 

shared  libraries.  The  dynamic  loader  attaches  each  required 
library  to  the  process  and  resolves  all  symbolic  references 
between  the  program  and  its  libraries.  The  text  segment  of 
a  shared  library  is  shared  among  all  processes  that  use  the 
library. 
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Environment  Variables 

Arguments  can  be  passed  to  the  linker  through  the  LDOPTS 
environment  variable  as  well  as  on  the  command  line.  The 
linker  picks  up  the  value  of  LDOPTS  and  places  its  contents 
before  any  arguments  on  the  command  line. 

Hie  LD  PXDB  environment  variable  defines  the  full  execution 
path  for  the  debug  preprocessor  pxdb.  Hie  default  value  is 
Ausr/bitVlpxdb.  Id  invokes  pxdb  on  its  output  file  if  that 
file  is  executable  and  contains  debug  information.  To  d  > 
invocation  of  pxdb  until  the  first  debug  session,  set 
LD_PXDB  to  /dev/null. 

Options 

Id  recognizes  the  following  options: 


-a  search 


-b 


-d 


-e  epsym 


■h  symbol 


Specify  v^ether  shared  or  archive 
libraries  are  searched  vdth  the  -1 
option.  Hie  value  of  search  should  be 
one  of  archive,  shared,  or  default. 

Hiis  option  can  appear  more  than  once, 
interspersed  among  -1  options,  to 
control  the  searching  for  each  library. 
Hie  default  is  to  use  the  shared  version 
of  a  library  if  one  is  available,  or  the 
archive  version  if  not.  If  either 
archive  or  shared  is  active,  only  the 
specified  library  type  is  accepted. 

Create  a  shared  library  rather  than  a 
normal  executable  file,  (^ject  files 
processed  with  this  option  should 
contain  TOsition  independent  code  (PIC) . 
See  the  discussion  of  PIC  in  cc(l) , 
f77(l),  £C(1),  and  as(l) . 

Forces  definition  of  ''common"  storage; 
i.e.,  assign  addresses  and  sizes,  for  -r 
output. 

Set  the  default  entry  point  address  for 
the  output  file  to  be  that  of  the  symbol 
epsym.  (Hiis  option  only  applies  to 
executable  files.) 

Prior  to  writing  the  symbol  table  to  the 
output  file,  mark  this  name  as  "local" 
so  that  it  is  no  longer  externally 
visible.  Hiis  ensures  that  this 
particular  entry  will  not  clash  with  a 
definition  in  another  file  during  future 
processing  Id.  (Of  course,  this  only 
makes  sense  witH  the  -r  option. )  More 
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than  one  symbol  can  be  specified,  but  -h 
must  precede  each  one. 

-lx  Search  a  library  litoc.a  or  libx.sl, 

vhere  x  is  one  or  more  characters.  The 
current  state  of  the  -a  option 
determines  whether  the  archive  ( .a)  or 
shared  (.si)  version  of  a  library  is 
searched.  Because  a  library  is  searched 
\dien  its  name  is  encountered,  the 
placement  of  a  -1  is  significant.  By 
default,  libraries  are  located  in  /lib 
and  Aisr/lib.  If  the  environment 
variable  LPAIH  is  present  in  the  user's 
environment,  it  should  contain  a  colon- 
separated  list  of  directories  to  search. 
These  directories  are  searched  instead 
of  the  default  directories,  but  -L 
options  can  still  be  used.  If  a  program 
uses  shared  libraries,  the  dynamic 
loader  /lib/dld.sl  will  attest  to  load 
each  library  from  the  same  directory  in 
^diich  it  was  found  at  link  time. 

Produce  a  load  map  on  the  standard 
ou^nit. 

Generate  an  (executable)  output  file 
with  code  to  be  shared  by  edl  users. 
Compare  with  -N. 

Produce  an  output  object  file  by  the 
name  outfile  (default  name  is  a. out). 

Generate  an  (executable)  output  file 
that  is  demand-loadable.  Ccopare  with 
-Q. 

Retain  relocation  information  in  the 
output  file  for  subsequent  re-linking. 
The  Id  command  does  not  report  undefined 
symbols.  The  -r  option  is  incompatible 
with  -A  and  -b. 

Strip  the  output  file  of  all  symbol 
table,  relocation,  and  debug  s\;Q^rt 
information.  This  micbt  inpair  or 
prevent  the  use  of  a  symbolic  debugger 
on  the  resulting  program.  This  option 
is  inconpatible  with  -r.  (The  strip(l) 
command  also  removes  this  information. ) 

Print  a  trace  (to  standard  output)  of 
each  input  file  as  ^  processes  it. 


-n 


outfile 


-r 


-s 


-t 
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■u  symbol 


-V 


~x 


-2 


-A  name 


-B  bind 


Enter  symtol  as  an  iindefined  symbol  in 
the  symbol  table.  Hie  resulting 
unresolved  reference  is  useful  for 
linking  a  program  solely  from  object 
files  in  a  library.  More  than  one 
symbol  can  be  specified,  but  each  must 
be  preceded  by  -u. 

Display  verbose  messages  during  linking. 
For  each  library  module  that  is  loaded, 
the  linker  indicates  idiich  symbol  caused 
that  module  to  be  loaded. 

Parti2dly  strip  the  output  file;  that 
is,  leave  out  local  syntols. 
intention  is  to  reduce  the  size  of  the 
output  file  vdthout  in^iring  the 
effectiveness  of  object  file  utilities. 
Mote:  use  of  -x  mic^t  affect  the  use  of 
a  debugger. 

Arrange  for  nsi-time  dereferencing  of 
null  pointers  to  produce  a  SIGSEGV 
signal.  (This  is  the  complement  of  the 
-Z  option.) 

This  option  specifies  incremental 
loading.  Linking  is  arranged  so  that 
the  resulting  object  can  be  read  into  an 
already  executing  program.  Hie  argument 
name  specifies  a  file  \^ose  symbol  table 
provides  the  basis  for  defining 
additional  syndsols.  Only  newly  linked 
materied  is  entered  into  the  text  and 
data  portions  of  a. out,  but  the  new 
symbol  table  reflects  all  symbols 
defined  before  and  after  the  incremental 
load.  Also,  the  -R  option  can  be  used 
in  conjunction  with  -zA,  which  allows  the 
newly  linked  segment  to  ccmmence  at  the 
corresponding  address.  The  default 
starting  address  is  the  old  value  of 
jend.  The  -rA  option  is  incompatible 
with  -r  and  -b. 


Select  run-time  binding  behavior  of  a 
program  using  shared  libraries.  Hie 
value  of  bind  must  be  one  of  immediate 
or  deferred.  The  default  is  deferred, 
which  tells  the  dynamic  loader 
/lib/dld.sl  to  resolve  procedure  calls 
on  first  reference  rather  than  at 
program  start-up  time. 
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-E 


-L  dir 


-N 


-Q 


-R  offset 


-V  num 


■X  num 


-Z 


Mack  all  syndaols  defined  by  a  program 
for  export  to  shared  libraries.  By 
default,  ^  can  mark  only  those  symbols 
that  are  actually  referenced  by  a  shared 
library. 

Change  the  algorithm  of  searching  for 
libx.a  or  litac.sl  to  look  in  dir  before 
loolcing  in  delault  locations.  More  than 
one  directory  can  be  specified,  but  each 
must  be  preceded  by  -L.  The  -L  option 
is  effective  only  if  it  precedes  the  -1 
option  on  the  cnmnand  line. 

Generate  an  (executable)  output  file 
that  cannot  be  shared.  This  option  also 
causes  the  data  to  be  placed  immediately 
following  the  text,  and  makes  the  text 
writable. 

Generate  an  (executable)  output  file 
that  is  not  demand-loadable.  (This  is 
the  conplement  of  the  -g  option. ) 

Set  the  origin  (in  hexadecimal)  for  the 
text  (i.e.,  code)  segment. 

Use  num  as  a  decimal  version  stamp 
identifying  the  a. out  file  that  is 
produced.  This  is  not  the  same  as  the 
version  information  reported  by  the  SCCS 
vtot  (1)  command,  nor  is  it  the  same  as 
the  version  information  recorded  for 
shared  library  \ise. 

Define  the  initial  size  for  the  linker's 
globed  symbol  table.  This  reduces  link 
time  for  very  large  programs,  especially 
those  with  a  large  number  of  external 
symbols. 

Arrange  to  allow  run-time  dereferencing 
of  null  pointers>  See  the  discussions  of 
-Z  and  pointers  in  cc(l).  (This  is  the 
cooplement  of  the  -z  option. ) 


Defaults 

Unless  otherwise  directed,  ^  names  its  output  a. out.  The 
-o  option  overrides  this.  Executable  output  files  can  be 
shared.  The  defaidt  state  of  -a  is  to  search  shared 
libraries  if  available,  archive  libraries  otherwise.  The 
defaidt  bind  behavior  is  deferred. 
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EXTERNAL  INFLUENCES 
Environment  Variables 

LANG  determines  the  language  in  which  messages  are  displayed 
(Series  700/800  only). 

If  LANG  is  not  specified  or  is  set  to  the  espty  string,  a 
default  of  "C"  (see  lanq(5))  is  used  instead  of  LM4G. 

If  any  internationalization  variable  ccmtains  an  invalid 
setting,  U  behaves  as  if  all  internationalization  variables 
are  set  to  "C".  See  environ(5). 

DIAGNOSTICS 

Id  returns  zero  when  the  link  is  successful.  A  non-zero 
return  code  indicates  that  an  error  occurred. 

EXAMPLES 

The  following  command  line  links  part  of  a  C  program  for 
later  processing  by  Id.  It  also  specifies  a  version  number 
of  2  for  the  output  Tile.  (Note  the  .o  suffix  for  the 
outpit  object  file.  This  is  an  HP-UX  convention  for 
indicating  a  linkable  object  file. ) 

Id  -V  2  -r  filel.o  file2.o  -o  prog.o 

The  next  example  links  a  siaple  FORTRAN  program  for  use  with 
the  cdb(l)  symbolic  debugger.  The  output  file  name  will  be 
a. out  since  there  is  no  -o  option  in  the  command  line. 

(Note:  the  particular  options  shown  here  are  for  a  Series 
300/400  system.) 

Id  -e  start  /lib/frtO.o  ftn.o  -1177  -1F77  -Im  -Ic 
/^r/lib/end .  o 

This  example  creates  a  shared  library. 

Id  -b  -o  libfunc.sl  funcl.o  func2.o  func3.o 

Link  a  program  with  libfunc.sl  but  use  the  archive  version 
of  the  C  library: 

Id  /lib/crtO.o  program.o  -L  .  -Ifunc  -a  archive 
-Ic 

Link  a  Pascal  program  on  a  Series  300/400  system: 

Id  /lib/crtO.o  main.o  -Ipc  -Im  -Ic 


WARNINGS 

Id  recognizes  several  names  as  having  special  meanings.  The 
symbol  end  is  reserved  by  the  linker  to  refer  to  the  first 
address~beyond  the  end  of  the  program's  address  space. 
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Similarly^  the  symbol  _edata  refers  to  the  first  address 
beymd  the  initialized  data,  and  the  symbol  etext  refers  to 
the  first  address  beyond  the  program  text,  ihe  linker 
treats  a  user  definition  of  any  of  these  symbols  as  an 
error.  The  symbols  end,  edata,  and  etext  are  also  defined 
by  the  linker,  but  only  if  the  program  contains  a  reference 
to  these  symbols  and  does  not  (tefine  them  (see  end(3C)  for 
details). 

Throu^  its  options,  the  link  editor  gives  users  great 
flexibility.  However,  those  %dio  invoke  the  linker  directly 
must  assume  some  added  responsibilities.  Input  options 
should  ensure  the  following  properties  for  programs: 

e  When  the  link  editor  is  called  through  cc( 1 ) ,  a 
start-up  routine  is  linked  with  the  user's  program. 
Ihis  routine  calls  exit(2)  after  execution  of  the 
main  program.  If  users  call  Id  directly,  they  must 
ensure  that  the  program  always  calls  exit( )  rather 
than  falling  through  the  end  of  the  entry  routine. 

e  When  linking  for  tise  with  the  symbolic  debu^er  cdb, 
the  user  must  ensure  that  the  program  contains  a 
routine  called  main.  Also,  the  tiser  must  link  in 
the  file  Aisr/lib/end.o  as  the  last  file  named  on 
the  command  line. 

There  is  no  guarantee  that  the  linker  will  pick  up  files 
from  archive  libraries  and  include  them  in  the  final  program 
in  the  same  relative  order  that  they  occur  within  the 
library. 

DEPENDEZTCIES 

Series  300/400 

Itie  default  entry  point  is  taken  to  be  text  location 
0x0  (which  is  aXso  the  default  origin  of  the  pr^ram 
text)  if  shared  libraries  are  not  used.  Otherwise,  the 
entry  point  is  taken  to  be  the  first  text  location 
after  the  extension  header  placed  at  the  beginning  of 
the  text  segment  by  Id  for  use  by  /lib/dld.sl.  This 
corresponds  to  the  fI7st  procedure  in  the  first  input 
file  that  the  linker  reads.  If  the  C  startup  routine 
/lib/crtO.o  is  the  first  object  file  on  the  command 

line,  the  label  start  denotes  the  entry  point.  Use  the 
-e  option  to  select  a  different  entry  point. 

The  version  nxjmber  specified  with  the  -V  option  must  be 
in  the  range  0  through  32767.  Use  of  this  option  is 
not  recommended  because  this  field  is  vised  by  several 
HP-UX  commands  that  expect  particular  values  here. 
Consult  the  C  Prc^rammer's  Guide  for  more  details  on 
the  version  7ield. 
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The  placement  of  -L  options  relative  to  -1  is  not 
significant. 

The  Series  300/400  linker  does  not  si:^)port  the 
following  options:  -m,  -z,  and  -Z. 

On  Series  300/400  systems,  the  ccoopilers  place  an 
underscore  at  the  beginning  of  all  external  names. 

Thus,  the  syndx)!  jend  appears  to  the  linker  as  end. 

Id  does  not  generate  an  output  file  if  any  other  errors 
occur  during  its  operation. 

Series  700/800 

The  linker  searches  for  the  symbol  $SThRT$  as  the 
program  entry  point.  This  symbol  is  defined  in  the 
file  /lib/crtO.o,  which  should  be  the  first  file  loaded 
for  all  programs  regardless  of  source  language.  Use 
the  -e  option  to  select  a  different  entry  point. 

When  invoking  Id  directly  to  link  a  C  program  vihose 
main  procedure~Ts  located  in  a  library,  the  -u  main 
option  should  be  tised  to  force  the  linker  to  load  main 
from  the  library,  since  this  symbol  is  not  actually 
referenced  until  the  _start  routine  is  loaded  frcn  the 
C  library.  When  using  cc(l)  to  link  the  program,  the 
ccopiler  automatically  passes  this  option  to  the 
linker.  Because  of  this  behavior,  do  not  use  cc  to 
link  a  program  containing  a  FORTRAN  or  Pascal  main 
program;  use  f77  or  jgc  instead. 

Nonsharable,  executable  files  generated  with  the  -44 
option  cannot  be  executed  via  exec(2).  Typically,  -N 
is  used  \^en  rebuilding  the  kernel  or  >dien  preparing  an 
image  for  dynamic  loading. 

When  the  -A  option  is  iised  to  do  an  incremental  link, 
the  linker  generates  extra  code  where  a  procedure  call 
crosses  a  quadrant  boundary  (a  quadrant  is  one 
gigabyte,  or  one  fourth  of  the  addressing  space).  On 
Series  700/800  systems,  text  is  normally  in  the  first 
quadrant  and  data  is  in  the  second  quadrant.  When  an 
^ject  file  is  intended  to  be  read  into  an  already- 
executing  program,  both  its  code  and  data  must  be 
placed  in  the  second  quadrant,  since  the  first  quadrant 
is  set  to  read-only.  Procedure  calls  from  one  quadrant 
to  the  other  require  the  extra  code,  called  inter-space 
calling  stubs.  The  linker  generates  an  "export"  stub 
for  the  entry  point  designated  in  the  incremental  link, 
and  "ioqport"  stubs  for  each  procedure  in  the  basis 
program  that  is  called  by  the  new  object  file.  The 
isqport  stubs  require  the  existence  of  a  routine  in  the 
basis  program  called  j5r4export,  which  is  sv^lied  in 
/lib/crtO.o.  If  a  procedure  in  the  basis  program  is 
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called  indirectly  the  new  object  file,  the  linker 
cannot  detect  the  crossing  of  the  quadrant  boundary, 
and  therefore  will  not  generate  the  needed  stub.  A 
special  version  of  $$c^call  placed  in  /lib/dyncall.o 
is  provided  for  handling  the  inter-quadrant  branch. 
This  routine  should  be  linked  in  vdien  the  -A  option  is 
in  effect. 

Ihe  Series  700/800  linker  does  not  siqpport  the  -V 
option. 

The  following  options  are  specific  to  the  Series 
700/800  linker: 

-y  symbol  Indicate  each  file  in  \diich  symbol 
appears.  Many  such  options  can  be 
given  to  trace  many  symbols,  but  -y 
must  precede  each  one. 

-Ch  Set  the  maximum  parameter-checking 

level  to  n.  The  default  maximum  is 
3.  See  tEe  language  manuals  for  the 
meanings  of  the  parameter-checking 
level. 

-0  offset  Set  the  origin  ( in  hexadecimal )  for 
the  data  space.  The  default  v^ue 
for  offset  is  0x40001000. 

-G  Strip  all  unloadable  data  from  the 

output  file.  This  option  is 
typically  used  to  strip  debug 
information. 

-S  Generate  an  Initial  Program  Loader 

(IFL)  auxiliary  header  for  the  output 
file,  instead  of  the  default  HP-UX 
auxiliary  header. 

-T  Save  the  load  data  aixi  relocation 

information  in  tes^mrary  files 
instead  of  memory  during  linking. 

This  option  reduces  the  virtiial 
memory  requirements  of  the  linker. 

If  the  TMPDIR  environment  variable  is 
set,  the  tenporary  files  are  created 
in  the  specified  directory,  rather 
than  in  /tmp. 

Id  treats  both  di:^licate  symbols  and  unresolved  symbols 
In  the  same  manner:  an  output  file  is  generated  and 
marked  as  non-executable  if  errors  occur  during  its 
operation. 
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AUTHOR 

Id  was  developed  by  AT&T,  the  Itoiversity  of  California, 
Berkeley,  and  HP. 

FILEIS 

/lib/libK.a 
/\asr/lib/lihoc. 

/lib/1  ibx.  si 
/Usr/lib/litoc. 
a. out 

/lib/dld.sl 

Series  300/400 
Aib/crtO.o 
Aib/incrtO.o 

Aib/gcrtO.o 

Aib/frtO.o 
Aib/tafrtO.o 

Aib/gfrtO.o 

AisrAib/end.o 

Series  700/800 
Aib/crtO.o  run-time  start-up 

Aib/dyncall.o  used  with  -A-option  links 
Aib/tacrtO.o  run-time  start-up  with  profiling  (see 

prof(l)) 

Aib/tailli.a  Unicode  library  automatically  searched 

by  Id 

Aib/gcrtO.o  run-time  start-x^  with  profiling  (see 

fprofd)) 

or  xise  with  xdb(l) 

/\isrAib/nls/$LftNGAd .  cat 

message  catalog 
/tmpAd*  temporary  files 

SEE  ALSO 

ar(l),  cc(l),  cdb(l),  f77(l),  gprof(l),  nm(l),  pc(l), 
prof(l),  strip(l),  exec(2),  crt0(3),  end(3C),  a.out(4), 
ar(4),  dld.sKS). 


archive  libraries 
a  archive  libraries 

shared  libraries 
si  shared  libraries 

output  file 
dynamic  loader 


run-time  start-up  for  c  and  Pascal 
run-time  start-up  for  c  and  Pascal 
with  profiling  (see  prof(l) ) 
run-time  start-up  for  C  and  Pascal 
with  profiling  (see  gprof(l) ) 
run-time  start-up  for  FORTRAN 
run-time  start-up  for  FORTRAN  with 
profiling  (see  prof (1) ) 
run-time  start-up  for  FORTRAN  with 
profiling  ( see  gprof ( 1 ) ) 
for  use  with  cdb/fdb/p^(l) 


on  HP-UX  manual. 


STANDARDS  CONFORMANCE 
Id:  SVID2,  XPG2 
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Ttie  only  allowed  inplementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventions 
as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  Die  implementation-dependent 
characteristics  of  this  Ada  inplementation,  as  described  in  this  i^pendix, 
are  provided  by  the  customer.  unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  conpiler  documentation  and  not  to  this 
report.  Inplementation-specific  portions  of  the  package  STANDARD,  which 
are  not  a  part  of  ^pendix  F,  are: 


package  STANDARD  is 


type  SHORT_SHORT_INTEGER  is  range  -128  ..  127; 

type  SHORT^INTECasi  is  range  -32768  ..  32767; 

type  INTEGER  is  range  -2147483648  ..  2147483647; 

type  FLOAT  is  digits  6  range  -3.402823&t-38  ..  3.402823E+38; 

type  LONG  FLOAT  is  digits  15  range 

-1.7?7693134862315E+308  ..  1.797693134862315E+308; 

type  DURATION  is  delta  2#0. 00000000000001#  range 
-86400.0  ..  86400.0; 

•  •  • 

end  STANDARD; 
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Preface 

This  manual  describes  the  implementation-dependent  characteristics  of  the 
HP  Ada  Development  System  on  the  HP  9000  Precision  Architecture  RISC 
(PA-RISC)  machines.  The  PA-RISC  family  includes  the  HP  9000  Series  600, 
700,  and  800  systems.  In  this  manual,  the  term  “Ada”  refers  to  the  Ada 
Development  System  running  on  any  Series  600,  700,  or  800  computer  system. 
This  compiler  has  been  validated  using  the  Ada  Compiler  Validation  Capability 
(ACVC)  test  suite  from  the  Ada  Joint  Program  Office. 

This  manual  provides  information  on  machine  dependencies  as  stipulated  in  the 
Reference  Manual  for  the  Ada  Programming  Language  {Ada  RM).  This  manual 
describes  the  following: 

■  HP  implementation-dependent  pragmas  and  attributes. 

■  Specifications  of  the  packages  SYSTEM  and  STANDARD. 

■  Instructions  on  using  type  representation  clauses  to  fully  specify  the  layout  of 
data  objects  in  memory. 

■  Restrictions  on  unchecked  type  conversions. 

■  Implementation-dependent  characteristics  of  input/output  packages. 

■  Information  about  HP-UX  signals  and  the  Ada  runtime  environment. 

■  Instructions  and  examples  on  calling  external  subprograms  written  in 
Precision  Architecture  RISC  Assembly  Language.  HP  C,  HP  FORTRAN  77, 
and  HP  Pascal. 
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The  following  manuals  provide  additional  information  about  the  topics 
indicated  (Hewlett-Packard  part  numbers  are  listed  in  parentheses): 


Ada 

■  Reference  Manual  for  the  Ada  Programming  Language 
United  States  Department  of  Defense 
ANSI/MIL-STD-1815A-1983 

Order  Number  008-000-00394-7 

U.S.  Government  Printing  Office,  Washington  DC  20402 
(97055-90610) 

■  Ada  User’s  Guide 
(B2425-90002) 

■  Ada  Tools  Manual 
(B2425-90005) 


HP-UX  Operating  System 

■  HP-  UX  Reference:  HP  9000  Computers,  3  Volumes 
(B2355-90004) 

■  Programming  on  HP-UX 
(B2355-90010) 

■  Device  I/O:  User’s  Guide 
(B 1862-90002) 

■  HP-UX  Portability  Guide 
(B1864-90006) 

■  Terminal  Control:  User’s  Guide 
(B1862-90013) 


Vi 


Precision  Architecture  RISC  Procedure  Calling  Convention 

■  PA-RISC  Architecture  Procedure  Calling  Convention  Reference  Manual 
(09740-90015) 


Precision  Architecture  RISC  Assembly  Language 

■  Assembly  Language  Reference  Manual 
(92432-90001) 

■  ADB  Tutorial 
(92432-90005) 


C  Language 

■  HP  C/HP~UX  Reference  Manual 
(92453-90024) 

■  HP  C  Programmer’s  Guide 
(92434-90002) 


HP  FORTRAN  77 

■  HP  FORTRAN  77/HP-UX  Reference  Manual 
(92430-90005) 

■  HP  FORTRAN  77/HP-UX  Programmer’s  Reference 
(92430-90004) 
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HP  Pascal 

■  HP  Pascal/HP-  UX  Reference  Manual 
(92431-90005) 

■  HP  Pascal/HP-UX  Programmer’s  Guide 
(92431-90006) 

■  HP  Pascal/HP-  UX  Quick  Reference  Guide 
(92431-90007) 


NFS®  Systems 

■  Using  NFS  Services 
(B1013- 90000) 

■  Installing  and  Administering  NFS  Services 
(B1013-90001) 


NFS®  is  a  trademark  of  SUN  Microsystems,  Inc. 
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Conventions 

lowercase  nonbold 

lowercase  boldface 

italics 

[  ] 


underlining 


In  syntax,  represents  literals;  items  are  to  be  entered 
exactly  as  shown. 

In  syntax,  represents  Ada  language  reserved  words. 

Represents  parzmieters  which  must  be  replaced  by  a 
user-supplied  \’ariable. 

Specifies  that  an  element  inside  brackets  is  optional. 

When  several  elements  are  separated  vertically  by  bars 
in  a  syntax  statement,  the  user  must  select  one  of  these 
elements.  For  example: 

A  I  B  I  C 

User  must  select  .4  or  B  or  C. 

In  a  syntax  statement,  when  several  elements  are 
separated  by  bars,  underling  indicates  the  default  value. 
For  example, 

ALL  I  CURRENT 
CURRENT  is  the  default  value. 

A  horizontal  ellipsis  in  a  syntax  statement  indicates 
that  a  previous  element  can  be  repeated.  For  example: 

Citenmame. . .] 

Within  examples,  ellipsis  indicate  when  portions  of  the 
example  are  omitted. 
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F  1.  Implementation  Supported  Pragmas 


This  section  describes  the  predefined  language  pragmas  and  the  Ada 
implementation-specific  pragmas.  Table  1-1  lists  these  pragmas. 


Table  1-1.  Ada  Pragmas 


Action 

Pragma  Name 

Interface  with  subprograms  written  in  other 
languages 

lUTERFACE 

INTERFACE.HAME 

Support  text  processing  tools 

INDENT 

LIST 

PAGE 

Determine  the  layout  of  array  and  record  types 
in  memory 

PACK 

IMPROVE 

Direct  the  compiler  to  generate  different  code 
than  what  is  normally  generated 

ELABORATE 

INLINE 

SUPPRESS 

Affect  tasking  programs 

PRIORITY 

SHARED 

Allows  Ada  code  and  data  objects  to  be 
referenced  by  a  non-Ada  external  subprogram. 

EXPORT 

EXTERN AL.NAME 

See  section  “F  1.6  Pragmas  Not  Implemented”  for  a  list  of  predefined  pragmas 
not  implemented  in  .Ada. 
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F  1.1  Interfacing  the  Ada  Language  with  Other  Languages 

Your  Ada  programs  can  call  subprograms  written  in  other  languages  when  you 
use  the  predefined  pragmas  INTERFACE  and  INTERFACE.NAME.  Ada  supports 
subprograms  written  in  these  languages: 

■  PA- RISC  Assembly  Language. 

■  HP  C. 

■  HP  Pascal. 

■  HP  FORTRAN  77  for  HP  9000  Series  600,  700,  and  800  computers. 

Compiler  products  from  vendors  other  than  Hewlett-Packard  may  not  conform 
to  the  parameter  passing  conventions  given  below.  See  section  “F  11.  Calling 
External  Subprograms  from  Ada”  for  detailed  information,  instructions,  and 
examples  for  interfacing  your  Ada  programs  with  the  above  languages. 

In  addition,  data  objects  declared  in  other  languages  can  be  made  accessible 
to  Ada  by  using  the  ’IMPORT  attribute  of  the  SYSTEM .  ADDRESS  type  (see 
“F  2.2  Attribute  SYSTEM.ADDRESSIMPORT”  in  Chapter  2).  Data 
objects  declared  in  a  global  Ada  scope  can  be  referenced  by  a  non- Ada 
external  subprogram  when  you  use  the  predefined  pragma  EXPORT.  Alternative 
names  for  a  global  Ada  data  object  can  be  defined  when  you  use  the  pragma 
EXTERNAL.NAME. 
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F  1.1.1  Pragma  INTERFACE 

The  pragma  INTERFACE  (Ada  RM,  section  13.9)  informs  the  compiler  that 
a  non- Ada  external  subprogram  will  be  supplied  when  the  Ada  program  is 
linked.  Pragma  INTERFACE  specifies  the  programming  language  used  in  the 
external  subprogram  and  the  name  of  the  Ada  interfaced  subprogram.  The 
corresponding  parameter  calling  convention  to  be  used  in  the  interface  is 
implicitly  defined  in  the  language  specification. 


Syntax 

pragma  INTERFACE  (Language^name,  Adasubprogram^name)  ; 


Parameter 

Description 

Language^name 

is  one  of  ASSEMBLER,  C,  PASCAL,  or  FORTRAN. 

Ada^subprogram^name 

is  the  name  used  within  the  Ada  program  when 
referring  to  the  interfaced  external  subprogram. 

It  is  possible  to  supply  a  pragma  INTERFACE  to  a  library-level  subprogram. 
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F  1.1^  Pragma  1NTERFACE.NAME 

Ada  provides  the  implementation-defined  pragma  INTERFACE.NAHE  to  associate 
an  alternative  name  with  a  non- Ada  external  subprogram  that  has  been 
specified  to  the  Ada  program  by  the  pragma  INTERFACE. 


Syntax 

pragma  INTERFACE.NAME  (.Ada^subprogram-name, 

" Extemal-subprogram^name")  ; 


Parameter 

Description 

Ada^subprogram^name 

is  the  name  when  referring  to  the  interfaced  external 
subprogram. 

ExiemaLs-ubprogram^name 

is  the  external  name  used  outside  the  Ada  program. 

You  must  use  pragma  INTERFACE.NAME  whenever  the  interfaced  subprogram 
name  contains  characters  not  acceptable  within  Ada  identifiers  or  when  the 
interfaced  subprogram  name  contains  uppercase  letter(s).  You  can  also  use 
a  pragma  INTERFACE.NAME  if  you  want  your  Ada  subprogram  name  to  bo 
different  than  the  external  subprogram  name. 

If  a  pragma  INTERFACE.NAME  is  not  supplied,  the  external  subprogram  name  is 
the  name  of  the  Ada  subprogram  specified  in  the  pragma  INTERFACE,  with  all 
alphabetic  characters  shifted  to  lowercase  letters. 

The  compiler  truncates  the  name  to  255  characters  if  necessary. 

Pragma  INTERFACE.NAME  is  allowed  at  the  same  places  in  an  Ada  program  as 
pragma  INTERFACE  (see  Ada  RM ,  section  13.9.)  Pragma  INTERFACE.NAME 
must  follow  the  corresponding  pragma  INTERFACE.  If  the  pragma  INTERFACE 
appears  in  a  declarative  part,  the  pragma  INTERFACE.NAME  must  appear 
within  the  same  declarative  pan.  although  it  need  not  immediately  follow  the 
pragma  INTERFACE.  If  the  pragma  INTERFACE  appears  outside  of  any  program 
unit,  as  it  does  when  being  applied  to  a  library-level  subprogram,  the  pragma 
INTERFACE.NAME  must  appear  after  the  pragma  INTERFACE  and  before  any 
subsequent  compilation  unit. 
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F  1.1.3  Example  of  INTERFACE  and  INTERFACE.NAME 

The  following  example  illustrates  the  INTERFACE  and  INTERFACE.NAME 
pragmas. 

package  SAMPLE.LIB  is 

function  SAMPLE.DEVICE  (X  :  INTEGER)  return  INTEGER; 
function  PROCESS.SAMPLE  (X  :  INTEGER)  return  INTEGER; 


private 

pragma  INTERFACE  (ASSEMBLER.  SAMPLE.DEVICE  ); 
pragma  INTERFACE  (C,  PROCESS.SAMPLE  ); 

pragma  INTERFACE.NAME  (SAMPLE.DEVICE,  "DevlO"  ); 
pragma  INTERFACE.NAME  (PROCESS.SAMPLE,  "DoSample"  ); 


end  SAMPLE.LIB; 


This  example  defines  two  Ada  subprograms  that  are  known  in  Ada  code  as 
SAMPLE.DEVICE  and  PROCESS.SAMPLE.  When  a  call  to  SAMPLE.DEVICE  is 
executed,  the  program  generates  a  cdl  to  the  externally  supplied  assembly 
function  DevlO.  Likewise,  when  a  call  to  PROCESS.SAMPLE  is  executed, 
the  program  will  generate  a  call  to  the  externally  supplied  HP  C  function 
DoSample. 

•By  using  the  pragma  INTERFACE.NAME,  the  names  for  the  external  subprograms 
to  associate  with  the  Ada  subprogram  are  explicitly  identified.  If  pragma 
INTERFACE.NAME  had  not  been  used,  the  external  names  referenced  would  be 
sample. device  and  process. sample. 
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F  1.1.4  Additional  Information  on  INTERFACE  and 
INTERFACE.NAME 

Either  an  object  file  or  an  object  library  that  defines  the  external  subprograms 
must  be  provided  as  a  command  line  parameter  to  the  Ada  binder.  The 
command  line  parameter  must  be  provided  to  the  linker  ld(l)  if  you  call 
the  linker  separately.  If  you  do  not  provide  an  object  file  that  contains  the 
definition  for  the  external  subprogram,  the  HP-UX  linker,  will  issue  an 

error  message. 

To  avoid  conflicts  with  the  Ada  Runtime  Sj'stem,  the  names  of  interfaced 
external  routines  should  not  begin  with  the  letters  “alsy”  or  “A_"  because  the 
Ada  runtime  system  prefixes  its  internal  routines  with  these  prefixes. 

When  you  want  to  call  an  HP-UX  system  call  from  Ada  code,  you  should  use 
a  pragma  INTERFACE  with  C  as  the  language  name.  You  might  need  to  use  a 
pragma  INTERFACE.NAME  to  explicitly  supply  the  external  name.  This  external 
name  must  be  the  same  as  the  name  of  the  system  call  that  you  want  to  call. 
(See  section  2  of  the  HP-UX  Reference  for  details.)  In  this  case  it  is  not 
necessary  to  provide  the  C  object  file  to  the  binder,  because  it  will  be  found 
automatically  when  the  linker  searches  the  system  library. 

When  you  want  to  call  an  HP-UX  library  function  from  Ada  code,  you  should 
use  a  pragma  INTERFACE  with  C  as  the  language  name.  You  should  use  pragma 
INTERFACE.NAME  to  explicitly  supply  the  external  name.  This  external  name 
must  be  exactly  the  same  as  the  name  of  the  library  function.  (See  section  3  of 
the  HP-  UX  Reference  for  details.  )  If  your  library  function  is  located  in  either 
the  Standard  C  Library  or  the  Math  Library,  it  is  not  necessary  to  provide  the 
object  library  to  the  binder  because  the  binder  always  requests  that  the  linker 
search  these'  two  libraries.  If  your  library  function  is  located  in  any  of  the  other 
standard  libraries,  you  must  provide  the  appropriate  -lx  option  to  the  binder. 
The  binder  will  pass  this  information  onto  the  linker  as  a  request  to  search  the 
specified  library. 


1'6  F  1.  Implementation  Supported  Pragmas 


Caution 


All  array  and  record  type  parameters  are  passed  by  reference 
from  Ada  code  to  non-Ada  interfaced  code.  In  particular, 
arrays  and  records  occupying  64  bits  or  less  of  storage  are 
passed  by  reference  and  are  not  passed  by  copy,  as  is  the 
standard  PA-RISC  calling  convention.  Therefore,  non-Ada 
code  expecting  to  receive  such  array  or  record  parameters 
must  expect  to  receive  them  by  reference,  not  by  copy.  C 
should  declare  such  parameters  to  be  appropriate  pointer  types: 
Pascal  should  declare  such  parameters  to  be  VAR  parameters; 
FORTRAN  always  expects  explicit  parameters  by  reference. 
Note  that  array  and  record  type  parameters  occupying  more 
than  64  bits  of  storage  are  passed  by  reference,  both  by  Ada 
and  by  the  standard  PA-RISC  calling  convention,  and  require 
no  special  precautions. 


See  section  “F  11.  Calling  E.xternal  Subprograms  From  Ada”  for  additional 
information  on  using  pragma  INTERFACE  and  pragma  INTERFACE.NAME. 
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F  1.1.5  Pragma  EXPORT 

The  pragma  EXPORT  allows  for  data  objects  and  subprograms  declared  in 
a  global  Ada  scope  to  be  referenced  by  a  non-Ada  externzJ  subprogram. 
Pragma  EXPORT  specifies  the  programming  language  and  the  name  of  the 
Ada  data  objer  or  subprogram.  The  default  name  for  the  externally  visible 
symbol  is  the  name  of  the  Ada  object  in  all  lowercase  letters.  The  pragma 
EXTERNAL.NAME  (described  in  section  “F  1.1.6  Pragma  EXTERNAL.NAME”) 
can  be  used  to  change  this  default. 


Syntax 

pragma  EXPORT  (.Language-name,  Ada-name)  ; 


Parani«ter 

Description 

Language-name 

is  one  of  ASSEMBLER,  C.  PASCAL,  or  FORTRAN. 

Ada-name 

is  the  simple  name  of  the  Ada  data  object  or  Ada 
subprogram  that  is  to  be  made  visible  to  a  non-Ada 
subprogram. 

The  pragma  EXPORT  must  occur  in  a  declarative  part  and  applies  only  to  data 
objects  or  subprograms  declared  in  the  same  declarative  part:  that  is,  generic 
instantiated  objects  or  renamed  objects  are  excluded.  In  addition,  if  an  .A.da 
subprogram  name  is  specified  to  pragma  EXPORT,  there  must  be  a  unique  Ada 
subprogram  with  that  name  (that  is.  the  Ada  subprogram  name  must  not  be 
overloaded).. 

The  pragma  EXPORT  can  only  be  used  for  data  objects  with  direct  allocation 
mode  (objects  are  allocated  with  indirect  allocation  mode  if  they  are  dynamic 
or  have  a  significant  size;  see  section  “F  4.9  Data  .Allocation”,  for  details)  and 
for  subprograms  that  are  declared  in  a  library  package  or  in  a  package  that  is 
ultimately  nested  in  a  library  package.  The  pragma  cannot  be  used  for  a  data 
object  or  subprogram  tlmi  is  declared  within  another  subprogram,  nor  can  it 
be  used  for  a  libiary  level  subprogram.  When  applied  to  an  .Ada  subprogram, 
the  pragma  EXPORT  is  additionally  restricted  to  only  being  specified  in  a  lilirarv 
package  specification. 
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The  pragma  EXPORT  cannot  be  used  for  a  subprogram  that: 

■  has  an  IN  OUT  or  OUT  parameter 

■  has  an  unconstrained  array  parameter 

■  has  a  task  type  parameter 

■  is  a  function  with  an  array  result  type 

■  is  a  function  with  a  record  result  type 

■  is  a  function  with  a  task  type  result  type 

■  has  a  pragma  INTERFACE  also  specified 

■  has  a  pragma  INLINE  also  specified 

When  using  pragma  EXPORT  with  one  or  more  Ada  subprograms,  the  main 

program  unit  must  be  an  Ada  procedure.  This  Ada  procedure  can  call  routines 

in  other  languages  that  themselves  call  Ada,  but  the  main  procedure  itself  must 

be  in  Ada. 

Caution  The  name  of  any  exported  subprogram  (either  the  default  name 
or  the  name  specified  by  pragma  EXTERNAL. NAME)  is  a  linker 
symbol  visible  to  all  components  of  the  application.  If  this 
name  happens  to  be  the  same  as  an  HP-UX  system  call,  it 
causes  program  failure  in  unexpected  situations.  For  example, 
if  the  name  of  your  exported  routine  is  close,  it  intercepts  all 
calls  to  the  system  routine  close (2).  This  causes  failure  of  the 
.\da  I/O  system. 

For  this  reason,  make  sure  that  the  name  you  choose  is  unique, 
and  not  either  a  system  call  or  in  use  by  some  other  part  of 
your  application. 


Following  is  an  example  of  pragma  EXPORT  applied  to  an  Ada  subprogram 
and  pragma  INTERFACE  applied  to  a  C  subprogram.  It  consists  of  two  files, 
callback. c  and  callback . ada,  and  compilation  directions. 
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The  ceillback.c  file  is  as  follows: 
extern  void  hi_there  (); 

/*  procedure  G0_T0_C  gets  called  from  Ada  MAIN,  adds  5  to 
argument,  and  calls  Ada  routine  HI.THERE  */ 
void  go.to.c  (c.arg) 
int  c.arg; 

{ 

hi.there  (c.arg  +  5) ; 

} 


The  callback. ada  file  is  as  follows: 

with  TEXT.IO; 
package  FROM.C  is 

—  Declaration  of  Ada  routine  HI.THERE,  to  be  called 
”  from  C.  This  must  be  in  a  library  package, 
procedure  HI.THERE  (ADA.ARG;  in  INTEGER); 

pragma  EXPORT  (C.  HI.THERE); 

end  FROM.C; 

package  body  FROM.C  is 

procedure  HI.THERE  (ADA.ARG:  in  INTEGER)  is 

—  This  procedure  called  from  C.  It  will  write  a 
--  message  including  the  value  passed  into  ADA.ARG. 
begin 

TEXT. 10. PUT. LINE  ("Now  in  Ada.  called  from  C!"); 

TEXT. 10. PUT. LINE 

("integer  passed  was"  A  INTEGER’ IMAGE  (ADA.ARG)) 
end  HI.THERE; 

end  FROM.C; 
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with  FROM.C;  —  ****  WITH  IS  NECESSARY  SO  FROM.C  GETS 
—  ****  INCLUDED  IN  PROGRAM 
procedure  MAIN  is 

—  This  is  an  Ada  main  procedure.  It  will  call  a  C  routine 

—  called  G0_T0_C,  passing  the  value  5  to  that  routine. 

—  G0_T0_C  will  call  the  Ada  routine  HI.THERE  to  demonstrate 

—  callbacks. 

—  The  C  routine  that  will  call  Ada: 
procedure  G0_T0_C  (C_ARG:  in  INTEGER); 
pragma  INTERFACE  (C,  GO.TO.C) ; 

begin 


--  Call  C.  C  will  then  call  Ada. 

GO.TO.C  (5); 

end  MAIN; 

To  compile  and  run  the  e.xample,  invoke  the  C  compiler  to  compile  callback. c 
and  produce  callback. o: 

cc  -c  callback. c 

Now  invoke  the  Ada  compiler  to  compile  callback. ada;  bind  and  link  it  with 
the  file  callback  .o. 

ada  callback. ada  ada_library_name  -M  main  callback. o 
Now  run  the  result: 
a.  out 

Now  in  Ada,  called  from  C! 
integer  passed  was  10 
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F  1.1.6  Pragma  EXTERNAL.NAME 

The  pragma  EXTERNAL.NAME  is  used  to  supply  an  alternate  externally  visible 
name  for  a  global  Ada  data  object  or  Ada  subprogram  that  has  been  exported 
using  a  pragma  EXPORT.  The  pragma  EXTERNAL.NAME  can  be  used  anywhere 
in  an  Ada  program  where  the  pragma  EXPORT  is  allowed.  The  pragma 
EXTERNAL.NAME  must  occur  after  the  corresponding  pragma  EXPORT  and  within 
the  same  library  package  as  the  corresponding  pragma  EXPORT. 


Syntax 

pragma  EXTERNAL.NAME  (Ada.nome,  "ExtemaLname")  ; 


Parameter 

Description 

Ada^name 

is  the  simple  name  of  the  Ada  data  object  or  Ada 
subprogram  that  is  to  be  made  visible  to  a  non-Ada 
subprogram. 

ExtemaLname 

is  the  externally  visible  name  that  is  to  be  accessed  in 
the  non-Ada  subprogram. 

'i'ou  must  use  the  pragma  EXTERNAL.NAME  whenever  the  externally  visible 
name  contains  cliaracters  not  acceptable  within  Ada  identifiers  or  when  the 
externally  visible  name  contains  an  uppercase  letter  or  letters.  You  can  also 
use  the  pragma  EXTERNAL.NAME  if  you  want  your  Ada  data  object  name  or  Ada 
subprogram  name  to  be  different  than  the  externally  visible  name. 

If  a  pragma  EXTERNAL.NAME  is  not  supplied,  the  externally  visible  name  is  the 
name  of  the  Ada  data  object  or  subprogram  specified  in  the  pragma  EXPORT, 
with  all  alphabetic  characters  shifted  to  lowercase  letters. 

The  compiler  truncates  the  name  to  25-5  characters  if  necessary. 
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F  1.1.7  Example  of  EXPORT  and  EXTERNAL.NAME 

The  following  example  illustrates  the  EXPORT  and  EXTERNAL_NAHE  pragmas, 
package  ADA.GLOBALS  is 

MY.INT  :  INTEGER; 

MY.CHAR  :  CHARACTER; 

procedure  MY.PROC  (X:  INTEGER); 

function  MY.IFUN  (A;  CHARACTER;  B:  SHORT. INTEGER) 

return  INTEGER; 

function  MY.FUNC  (Z:  BOOLEAN)  return  LONG.FLOAT; 
private 

pragma  EXPORT  (ASSEMBLER,  MY.INT) ; 
pragma  EXPORT  (C ,  MY.CHAR) ; 
pragma  EXPORT  (C,  MY.PROC); 
pragma  EXPORT  (C,  MY.IFUN); 
pragma  EXPORT  (C,  MY.FUNC); 

pragma  EXTERNAL.NAME  (MY.INT,  " Int. from. Ada" ) ; 
pragma  EXTERNAL.NAME  (MY.CHAR,  "Char.from.Ada") ; 
pragma  EXTERNAL.NAME  (MY.PROC,  "Proc.from.Ada") ; 
pragma  EXTERNAL.NAME  (MY.IFUN,  "Ifun.from.Ada") ; 
pragma  EXTERNAL.NAME  (MY.FUNC,  "Func.from.Ada") ; 

end  ADA.GLOBALS; 

This  example  defines  two  Ada  data  objects  that  are  known  in  Ada  code  as 
MY.INT  and  MY.CHAR  and  three  Ada  subprograms  that  are  known  in  Ada  code 
as  MY.PROC.  MY.IFUN,  and  MY.FUNC.  The  externally  visible  symbols  for  the 
data  objects  are.  respectively,  Int. from. Ada  and  Char.from.Ada  and  for  the 
subprograms,  Proc.from.Ada,  Ifim.from.Ada,  and  Func.from.Ada. 

By  using  the  pragma  EXTERNAL.NAME,  the  names  of  the  external  symbols  are 
explicitly  identified.  If  pragma  EXTERNAL.NAME  had  not  been  used,  the  external 
names  would  be  my. int.  my. char,  my.proc,  my.ifun,  and  my.func. 
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F  1.1.8  Pragma  EXPORT  Applied  to  Ada  Subprograms 

In  this  section,  the  term  “exported  Ada  subprogram”  refers  to  an  Ada 
subprogram  to  which  the  pragma  EXPORT  has  been  applied.  An  exported  Ada 
subprogram  can  be  called  from  Ada  code  as  usual;  the  subprogram  will  not 
behave  any  differently  just  because  the  pragma  EXPORT  has  been  specified. 

F  1. 1.8.1  Calling  an  Ada  Subprogram  from  Non-Ada  Code 

An  exported  Ada  subprogram  must  not  be  called  from  non-Ada  code  before 
the  body  of  the  exported  Ada  subprogram  has  been  elaborated.  If  non-.4da 
code  calls  an  exported  Ada  subprogram  prior  to  the  elaboration  of  the  Ada 
subprogram  body,  the  results  are  unpredictable  and  could  lead  to  program 
failure. 

When  calling  an  exported  Ada  subprogram  from  non-Ada  code,  the  parameters 
passed  to  Ada  from  non- Ada  code  must  be  compatible  with  the  data  types  and 
sizes  of  the  parameters  that  the  exported  Ada  subprogram  is  expecting. 

Exported  Ada  subprograms  can  only  have  parameters  of  mode  IN.  All  record 
and  array  parameters  must  be  passed  by  non-Ada  code  to  Ada  by  reference. 

If  an  exported  Ada  subprogram  has  default  parameter  values,  these  values 
are  ignored  when  the  exported  Ada  subprogram  is  called  from  non- Ada  code. 
Non-.Ada  code  must  always  pass  all  parameters  explicitly  to  Ada  code. 

With  respect  to  parameter  type  compatibility,  the  action  of  calling  an 
exported  Ada  subprogram  from  non- Ada  code  is  very  similar  to  calling 
non-Ada  code  (via  pragma  INTERFACE)  from  Ada  code.  Section  “F  11.  Calling 
External  Subprograms  From  Ada”,  describes  the  correspondences,  or  lack 
of  correspondences,  between  Ada  types  and  non-Ada  types  and  should  be 
consulted  for  information  on  which  non-Ada  objects  are  compatible  with  which 
Ada  objects. 
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Caution 


All  array  and  record  type  parameters  are  expected  to  be  passed 
by  reference  from  non-Ada  code  to  exported  Ada  code.  In 
particular,  arrays  and  records  occupying  64  bits  or  less  of 
storage  must  be  passed  by  reference  and  must  not  be  passed 
by  copy,  as  is  the  standard  PA-RISC  calling  convention. 
Therefore,  non- Ada  code  expecting  to  pass  such  array  or 
record  type  parameters  to  Ada  must  pass  such  parameters 
by  reference  not  by  copy.  C  must  pass  the  addresses  of  such 
parameters  cast  to  appropriate  pointer  types;  Pascal  must 
declare  such  parameters  to  be  VAR  parameters  in  the  EXTERNAL 
declaration;  FORTRAN  always  passes  explicit  parameters 
by  reference.  Note  that  array  and  record  type  parameters 
occupying  more  that  64  bits  of  storage  are  passed  by  reference, 
both  by  Ada  and  by  the  standard  PS-RISC  calling  convention, 
and  require  no  special  precautions. 


The  next  sections  describe  general  conditions  and  constraints  that  apply  to 
Ada  being  called  from  Assembly,  C,  FORTR.A.N,  and  Pascal. 

Assembler 

Ada  expects  any  parameter  passed,  except  LONG-FLOAT  by  value,  to  be 
passed  as  a  4  byte  quantity,  sign  extended  as  necessary,  in  the  location  (register 
or  memory)  appropriate  for  its  parameter  type  and  position  in  the  parameter 
list  (LONG-FLOAT  by  value  is  expected  to  be  passed  as  a  8  byte  quantity). 

C 

Ada  expects  any  parameter  passed,  except  LONG -FLOAT  by  value,  to  be 
passed  as  a  4  byte  quantity,  sign  extended  as  necessary,  in  the  location  (register 
or  memory)  appropriate  for  its  parameter  type  and  position  in  the  parameter 
list  (LONG-FLOAT  by  value  is  expected  to  be  passed  eis  a  8  byte  quantity). 

If  an  exported  .4da  subprogram  is  called  from  C,  and  C  is  operating  in 
non-ANSI  mode,  or  it  is  operating  in  .4NSI  mode,  but  lacks  a  function 
prototype  for  the  called  function.  C  will  convert  all  float  values  to  double 
when  passing  them  as  parameters.  Therefore,  passing  parameters  from  C 
to  Ada  when  Ada  is  expecting  a  parameter  of  type  FLOAT  requires  that  C  be 
operating  in  .4NSI  mode  with  a  function  prototype  for  the  Ada  subprogram. 


F  1.  Implementation  Supported  Pragmas  1*15 


FORTRAN 

The  exported  Ada  subprogram  parameters  that  correspond  to  parameters 
passed  explicitly  from  FORTRAN  must  all  be  of  an  access  type  or  of  type 
SYSTEM  .ADDRESS  as  FORTRAN  passes  such  parameters  by  reference. 

The  exported  Ada  subprogram  parameters  that  correspond  to  parameters 
passed  implicitly  from  FORTRAN  (such  as  the  length  of  a  FORTRAN  string 
parameter;  see  “F  11.4.4  String  Types  and  HP  FORTRAN  77  Subprograms” 
in  Chapter  11)  must  be  of  an  appropriate  scalar  type  (not  an  access  type  nor 
SYSTEM.ADDRESS).  This  type  is  usually  INTEGER. 

Pascal 

Ada  expects  any  parameter  passed,  except  LONG_FLOAT  by  value,  to 
be  passed  as  a  4  byte  quantity,  sign  extended  as  necessary,  in  the  location 
(register  or  memory)  appropriate  for  its  parameter  type  and  position  in  the 
parameter  list  (LONG_FLOAT  by  value  is  expected  to  be  passed  as  a  8  byte 
quantity).  The  exported  Ada  subprogram  parameters  that  correspond  to 
Pascal  VAR  parameters  must  all  be  of  the  appropriate  access  type  or  of  type 
SYSTEM.ADDRESS  as  Pascal  passes  such  parameters  by  reference.  Non-scalar 
parameters  can  only  be  passed  to  Ada  using  Pascal  VAR  parameters,  they  may 
not  be  passed  using  Pascal  value  parameters.  The  exported  Ada  subprogram 
parameters  that  correspond  to  Pascal  value  parameters  must  all  be  of  an 
appropriate  scalar,  access,  or  SYSTEM.ADDRESS  type  as  Pascal  passes  such 
parameters  by  value. 
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The  following  example  shows  C  calling  the  exported  Ada  subprograms 
MY.PROC,  MY.IFUN,  and  MY.FUNC  which  are  declared  in  the  ADA.GLOBALS 
example  given  in  “F  1.1.7  Example  of  EXPORT  and  EXTERNAL.NAME”: 

extern  void  Proc_froin_Ada  () ; 
extern  int  Ifim_froin_Ada  ()  ; 
extera  void  Func_froin_Ada  () ; 

call.ada  (i,  flag) 
short  i;  int  flag; 

double  dres; 
int  ires ; 
short  temp ; 

Proc_from_Ada  (i  *  28) ; 

ires  *  Ifun.from.Ada  i) ; 

Proc.from.Ada  (ires); 

/* 

♦  Note  the  conversion  of  ’flag’  to  the  appropriate  Ada  Boolean 

*  value. 

*/ 

dres  =  Func.from.Ada  (flag  ?  1  :  0) ; 

.  } 

F.1. 1.8.2  Exceptions 

An  exported  .Ada  subprogram  must  not  allow  an  exception  to  propagate  out  of 
itself  if  it  was  called  by  a  non-.4da  caller.  If  an  exception  is  propagated  back 
to  a  non-Ada  caller,  the  behavior  of  the  Ada  runtime  is  unpredictable  and  niav" 
result  in  program  failure.  If  the  exported  .Ada  subprogram  was  called  by  .Ada 
code  and  the  .Ada  subprogram  is  aware  of  that  fact,  it  can  safely  propagate 
exceptions  out  of  itself. 
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F.1. 1.8.3  Obtaining  the  Non-Ada  Call  Address  in  Ada  at  Runtime 

When  pragma  EXPORT  (and  optionally  pragma  EXTERNAL.NAHE)  is  applied 
to  an  Ada  subprogram,  an  externally  visible  name  is  created  such  that  the 
Ada  subprogram  can  be  called  directly  by  that  externally  visible  name  from 
non-Ada  code.  However,  the  Ada  code  may  need  to  obtain  the  address  of 
an  exported  Ada  subprogram  at  run  time.  For  example,  it  might  pass  such 
an  address  as  a  parameter  to  non- Ada  code  so  that  the  non- Ada  code  can 
use  the  address  to  call  an  Ada  subprogram  (a  “callback”  situation).  The 
function  EXPORTED.SUBPROGRAM  is  supplied  in  the  package  SYSTEM  to  obtain 
the  “non- Ada  call  address”  of  an  exported  Ada  subprogram.  The  function 
SYSTEM. EXPORTED.SUBPROGRAM  is  passed  a  single  parameter,  the  ’ADDRESS 
vzdue  of  an  exported  Ada  subprogram,  and  it  returns  the  address  which 
non-Ada  code  must  call  to  invoke  that  Ada  subprogram.  See  section  “F  3.1 
The  Package  SYSTEM”,  for  more  information. 


Caution  The  value  of  ’ADDRESS  of  an  exported  Ada  subprogram  is 
not  the  address  that  non- Ada  code  should  call  to  invoke 
the  exported  .4da  subprogram.  The  address  that  non-Ada 
code  must  call  to  invoke  an  Ada  subprogram  is  obtained  as 
the  result  of  passing  the  ’ADDRESS  value  of  the  exported  Ada 
subprogram  to  SYSTEM. EXPORTED.SUBPROGRAM;  the  function 
result  value  is  the  address  that  the  non- Ada  code  must  call.  If 
non-Ada  code  attempts  to  call  an  e.xported  Ada  subprogram 
using  the  'ADDRESS  value  for  that  subprogram,  the  result  is 
unpredictable  and  will  most  likely  result  in  program  failure. 
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F.1.1.B.4  Bind-Time  Issues 


1 


To  ensure  that  the  desired  exported  Ada  subprograms  are  present  in  the 
executable  program  produced  b}'  the  binder,  the  Ada  library  level  packages 
that  contain  those  exported  subprograms  must  be  “sithed”  into  at  least  one 
Ada  program  unit  that  will  be  present  in  the  executable  program.  No  special 
action  is  needed  if  the  Ada  program  already  uses  any  of  the  facilities  from  a 
library  level  package  that  contains  exported  Ada  subprograms  because  that 
package  will,  of  necessity,  already  be  “withed”  somewhere  in  the  program. 

Only  if  the  Ada  program  does  not  use  any  of  the  facilities  from  a  library  level 
package  that  contains  exported  Ada  subprograms  (for  example,  if  that  package 
only  contains  exported  Ada  subprograms  that  are  called  directly  from  non-Ada 
code),  will  it  be  necessary  to  take  extra  action  to  ensure  the  presence  of  the 
exported  Ada  subprograms  in  the  executable  program.  If  no  obvious  place  to 
‘•with”  such  a  package  exists,  the  package  can  always  be  ‘‘withed’'  into  the 
main  program  procedure. 


Note  The  Ada  binder  supports  a  mechanism  to  eliminate  uncalled 

subprograms.  Within  Ada  compilation  units,  subprograms 
that  are  never  called  (or  have  their  ’ADDRESS  taken)  can 
be  eliminated  from  the  executable  program  produced  by  the 
binder.  Because  exported  Ada  subprograms  legitimately  might 
never  be  called  by  Ada  code  (for  example,  if  they  are  only 
called  by  non-.Ada  code),  they  are  automatically  protected  from 
uncalled  subprogram  elimination.  Therefore,  if  your  program 
‘‘withed*’  a  library  level  package  that  declares  one  or  more 
exported  Ada  subprograms,  those  subprograms  will  always  be 
present  in  the  executable  file  produced  by  the  binder  (even  if 
they  are  also  not  called  from  non-Ada  code).  In  addition,  if  any 
of  the  exported  Ada  subprograms  call  other  Ada  subprograms, 
those  other  Ada  subprograms  (and  in  turn,  repeatedly,  any  .Ada 
subprograms  they  ccdl)  will  also  be  present  in  the  executable 
program.  Therefore,  care  must  be  taken  with  respect  to  the 
placement  of  exported  .Ada  subprograms  in  packages  and 
the  ‘‘withing”  of  those  packages  into  your  program  to  avoid 
including  in  your  executable  file  the  code  for  .Ada  subprograms 
that  your  program  does  not  call  (either  from  Ada  or  from 
nori-.Ada  code). 
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F.1. 1.8.5  HP-UX  Signal  Handlers  in  Ada 

Although  possible,  it  is  not  recommended  that  you  apply  the  pragma  EXPORT 
to  an  Ada  subprogram  so  that  the  Ada  subprogram  can  be  specified  as  an 
HP-UX  signal  handler.  If  you  do  so,  the  Ada  subprogram  that  is  to  act  as  a 
signal  handler  must  be  compiled  with  checks  off  (using  the  -R  option)  and  it 
must  not  call  any  Ada  runtime  system  routines.  The  Ada  subprogram  must 
not  call  HP-UX  routines  or  other  non-Ada  code,  either  via  pragma  INTERFACE 
or  via  a  binding.  If  the  Ada  subprogram  calls  another  Ada  subprogram,  the 
called  subprogram  must  follow  the  same  constraints. 

Using  the  interrupt  entry  mechanism  to  provide  Ada  subprograms  as  a  signal 
handlers  is  preferred.  This  is  described  in  section  “F  12.  Interrupt  Entries”. 
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F  1.2  Using  Text  Processing  Tools 

The  pragma  INDENT  is  a  formatting  command  that  affects  the  HP  supplied 
formatter,  ada.format(l).  This  pragma  does  not  affect  the  compilation  listing 
output  of  the  compiler.  The  pragmas  LIST  and  PAGE  are  formatting  commands 
that  affect  the  compilation  listing  output  of  the  compiler. 


F  1.2.1  Pragma  INDENT 

Ada  provides  the  implementation-defined  pragma  INDENT  to  assist  in 
formatting  Ada  source  code.  You  can  place  these  pragmas  in  the  source  code 
to  control  the  actions  of  ada.format(l). 


Syntax 

pragma  INDENT  (  ON  |  OFF  ) ; 


Parameter 

Description 

OFF 

ada. format  does  not  modify  the  source  lines  after  the  pragma. 

ON 

ada. format  resumes  its  action  after  the  pragma. 

The  default  for  pragma  INDENT  is  ON. 
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F  1.2.2  Pragma  LIST 

The  pragma  LIST  affects  only  the  compilation  listing  output  of  the  compiler. 
It  specifies  that  the  listing  of  the  compilation  is  to  be  continued  or  suspended 
until  a  LIST  pragma  with  the  opposite  argument  is  given  within  the  same 
compilation.  The  pragma  itself  is  always  listed  if  the  compiler  is  producing  a 
listing.  The  compilation  listing  feature  of  the  compiler  is  enabled  by  issuing 
one  of  the  compiler  options  -L  or  -B  to  the  ada(l)  command. 


Syntax 

pragma  LIST  (  ON  I  OFF  ) ; 


Parameter 

Description 

OFF 

The  listing  of  the  compilation  is  suspended  after  the  pragma. 

ON 

The  listing  of  the  compilation  is  resumed  and  the  pragma  is  listed. 

The  default  for  pragma  LIST  is  ON. 


F  1.2.3  Pragma  PAGE 

The  pragma  PAGE  affects  the  compilation  listing  output  of  the  compiler.  It 
specifies  that  the  program  text  which  follows  the  pragma  should  start  on  a  new 
page  (if  the  compiler  is  currently  producing  a  listing). 


Syntax 

pragma  PAGE; 


1-22  FI.  Implementation  Supported  Pragmas 


F  1.3  Affecting  the  Layout  of  Array  and  Record  Types 

The  pragmas  PACK  and  IMPROVE  affect  the  layout  of  array  and  record  types  in 
memory. 


F  1.3.1  Pragma  PACK 

The  pragma  PACK  takes  the  simple  name  of  an  array  type  as  its  only  argument. 
The  allowed  positions  for  this  pragma  and  the  restrictions  on  the  named  type 
are  governed  by  the  same  rules  as  for  a  representation  clause.  The  pragma 
specifies  that  storage  minimization  should  be  the  main  criterion  when  selecting 
the  representation  of  the  given  type. 


Syntax 

pragma  PACK  (array^type^name) ; 

The  pragma  PACK  is  not  implemented  for  record  types  on  Ada.  You  can  use  a 
record  representation  clause  to  minimize  the  storage  requirements  for  a  record 
type. 

The  pragma  PACK  is  discussed  further  in  section  “F  4.7  Array  Types.’* 


F  1.3.2  Pragma  IMPROVE 

The  pragma  IMPROVE,  an  implementation-defined  pragma,  suppresses  implicit 
components  in  a  record  type. 


Syntax 

pragma  IMPROVE  (  TIME  I  SPACE  ,  [ON  =>]  record^type-name)  ; 

The  default  for  pragma  IMPROVE  is  TIME.  This  pragma  is  discussed  further  in 
section  "F  4.8  Record  Types.” 
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F  1.4  Generating  Code 

The  pragmas  ELABORATE,  INLINE,  and  SUPPRESS  direct  the  compiler  to 
generate  different  code  than  would  have  been  normally  generated.  These 
pragmas  can  change  the  run  time  behavior  of  an  Ada  program  unit. 


F  1.4.1  Pragma  ELABORATE 

The  pragma  ELABORATE  is  used  when  a  dependency  upon  elaboration  order 
exists.  Normally  the  Ada  compiler  is  given  the  freedom  to  elaborate  library 
units  in  any  order.  This  pragma  specifies  that  the  bodies  for  each  of  the  library 
units  named  in  the  pragma  must  be  elaborated  before  the  current  compilation 
unit.  If  the  current  compilation  unit  is  a  subunit,  the  bodies  of  the  named 
library  units  must  be  elaborated  before  the  body  of  the  parent  of  the  current 
subunit. 


Syntax 

pragma  ELABORATE  (library  ^unit^name  i,  library  ^unit-name  2  ...  ); 


This  pragma  takes  as  its  arguments  one  or  more  simple  names,  each  of  which 
denotes  a  library  unit.  This  pragma  is  only  allowed  immediately  after  the 
context  clause  of  a  compilation  unit  (before  the  subsequent  library  unit  or 
secondary  unit).  Each  argument  must  be  the  simple  name  of  a  library  unit 
that  was  identified  by  the  context  clause.  (See  the  Ada  RM ,  section  10.5,  for 
additional  information  on  elaboration  of  library  units  .) 
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F  1.4.2  Pragma  INLINE 

The  pragma  INLINE  specifies  that  the  subprogram  bodies  should  be  expanded 
inline  at  each  call  whenever  possible;  in  the  case  of  a  generic  subprogram, 
the  pragma  applies  to  calls  of  its  instantiations.  If  the  subprogram  name 
is  overloaded,  the  pragma  applies  to  every  overloaded  subprogram.  Note 
that  pragma  INLINE  has  no  effect  on  function  calls  appearing  inside  package 
specifications. 

Syntax 

pragma  INLINE  (.subprogram-name  i.subprogram^name]  ...  ); 

This  pragma  takes  as  its  arguments  one  or  more  names,  each  of  which  is  either 
the  name  of  a  subprogram  or  the  name  of  a  generic  subprogram.  This  pragma 
is  only  allowed  at  the  place  of  a  declarative  item  in  a  declarative  part  or 
package  specification,  or  after  a  library  unit  in  a  compilation,  but  before  any 
subsequent  compilation  unit.  See  the  Ada  RM,  section  6.3.2,  for  additional 
information  on  inline  expansion  of  subprograms. 

This  pragma  can  be  suppressed  at  compile  time  by  issuing  the  compiler  option 
-I  to  the  ada(l)  command. 
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F  1.4.3  Pragma  SUPPRESS 

The  pragma  SUPPRESS  allows  the  compiler  to  omit  the  given  check  from  the 
place  of  the  pragma  to  the  end  of  the  declarative  region  associated  with  the 
innermost  enclosing  block  statement  or  program  unit.  For  a  pragma  given  in 
a  package  specification,  the  permission  extends  to  the  end  of  the  scope  of  the 
named  entity. 


Syntax 

pragma  SUPPRESS  (check-identifier  I,  [ON  =>]  name!  )  ; 


The  pragma  SUPPRESS  takes  as  arguments  the  identifier  of  a  check  and 
optionally  the  name  of  either  an  object,  a  type  or  subtype,  a  subprogram,  a 
task  unit,  or  a  generic  unit.  This  pragma  is  only  allowed  at  the  place  of  a 
declarative  item  in  a  declarative  part  or  a  package  specification. 

If  the  pragma  includes  a  name,  the  permission  to  omit  the  given  check  is 
further  restricted:  it  is  given  only  for  operations  on  the  named  object  or 
on  all  objects  of  the  base  type  of  a  named  type  or  subtype;  for  calls  of  a 
named  subprogram;  for  activations  of  tasks  of  the  named  task  type;  or  for 
instantiations  of  the  given  generic  unit.  (See  the  Ada  RM,  section  11.7,  for 
additional  information  on  suppressing  run  time  checks.) 

The  compiler  can  be  directed  to  suppress  all  run  time  checks  by  issuing  the 
compiler  option  -R  to  the  ada(l)  command.  The  compiler  can  also  be  directed 
to  suppress  all  run  time  checks  except  for  slack  checks  by  issuing  the  compiler 
option  -C  to  the  ada(l)  command. 
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F  1.5  Affecting  Run  Time  Behavior 

The  pragmas  PRIORITY  and  SHARED  affect  the  run  time  behavior  of  a  tasking 
program. 


F  1.5.1  Pragma  PRIORITY 

The  pragma  PRIORITY  specifies  the  priority  to  be  used  for  the  task  or  tasks  of 
the  task  type.  When  the  pragma  is  applied  within  the  outermost  declarative 
part  of  the  main  subprogram,  it  specifies  the  priority  to  be  used  for  the 
environment  task,  which  is  the  task  that  encloses  the  main  subprogram.  If  a 
pragma  PRIORITY  is  applied  to  a  subprogram  that  is  not  the  main  subprogram, 
it  is  ignored. 

Syntax 

pragma  PRIORITY  (.  static -expression) ; 

The  pragma  PRIORITY  takes  as  its  argument  a  static  expression  of  the 
predefined  integer  subtype  PRIORITY.  For  Ada,  the  range  of  the  subtype 
PRIORITY  is  1  to  16.  Note  that  during  an  entry  call  invoked  by  an  interrupt 
handler,  the  priority  of  a  task  is  temporarily  raised  to  a  value  higher  than 
PRIORITY ’LAST.  The  priority  value  is  specified  when  the  interrupt  handler  is 
installed:  see  section  “F  12.6  Associating  an  Ada  Handler  with  an  HP-UX 
Signal”,  for  details. 

•The  PRIORITY  pragma  is  only  allowed  within  the  specification  of  a  task  unit  or 
within  the  outermost  declarative  part  of  the  main  subprogram. 

These  task  priorities  are  only  relative  to  other  Ada  tasks  that  are  concurrently 
executing  with  the  environment  task.  This  pragma  does  not  change  the 
priority  of  an  Ada  task  or  the  .4da  environment  task  relative  to  other  HP-UX 
processes.  All  the  Ada  tasks  execute  within  a  single  HP-UX  process.  This 
HP-UX  process  executes  together  with  other  HP-UX  processes  and  is  scheduled 
by  the  HP-UX  kernal.  To  change  the  priority  of  an  HP-UX  process,  see  the 
command  nice(l).  See  the  Ada  RM.  section  9.8.  for  additional  information  on 
task  priorities. 
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F  1.5.2  Pragma  SHARED 

The  pragma  SHARED  specifies  that  every  read  or  update  of  the  variable  is 
a  synchronization  point  for  that  variable.  The  type  for  the  variable  object 
is  limited  to  scalar  or  access  types  because  each  read  or  update  must  be 
implemented  as  an  indivisible  operation. 

The  effect  of  pragma  SHARED  on  a  variable  object  is  to  suppress  the  promotion 
of  this  object  to  a  register  by  the  compiler.  The  compiler  suppresses  this 
optimization  and  ensures  that  any  reference  to  the  variable  always  retrieves  the 
value  stored  by  the  most  recent  update  operation. 


Syntax 

pragma  SHARED  (.variablesimple-name)  ; 

The  pragma  SHARED  takes  as  its  argument  a  simple  name  of  a  variable.  This 
pragma  is  only  allowed  for  a  variable  declared  by  an  object  declaration  and 
whose  type  is  a  scalar  or  access  type;  the  variable  declaration  and  the  pragma 
must  both  occur  (in  this  order)  within  the  same  declarative  part  or  package 
specification. 

See  the  Ada  RM,  section  9.11,  for  additional  information  on  shared  variables. 
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F  1.6  Pragmas  Not  Implemented 

The  following  predefined  language  pragmas  are  not  implemented  and  will  issue 
a  warning  at  compile  time: 

pragma  CONTROLLED  (access-typesimple^name) ; 
pragma  MEMORY_SIZE  (numeric^literal) ; 
pragma  OPTIMIZE  (TIME  I  SPACE) ; 
pragma  STORAGE.UNIT  inumeric-literal)  ; 
pragma  SYSTEM.NAME  (enumeration^Uieral) ; 

See  the  Ada  RM,  Appendix  B,  for  additional  information  on  these  predefined 
language  pragmas. 
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F  2.  Implementation-Dependent  Attributes 


In  addition  to  the  representation  attributes  discussed  in  the  Ada  RM , 
section  13.7.2,  there  are  five  implementation-defined  representation  attributes: 


•OFFSET 

•RECORD.SIZE 

•VARIANT.INDEX 

•ARRAY.DESCRIPTOR 

•RECORD.DESCRIPTOR 


These  implementation-defined  attributes  are  only  used  to  refer  to  implicit 
components  of  record  types  inside  a  record  representation  clause.  Using  these 
attributes  outside  of  a  record  representation  clause  will  cause  a  compiler  error 
message.  For  additional  information,  see  section  “F  4.8  Record  Types”. 
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F  2.1  Limitation  of  the  Attribute  ’ADDRESS 

The  attribute  '  ADDRESS  is  implemented  for  all  entities  that  have  meaningful 
addresses.  The  compiler  will  issue  the  following  warning  message  when  the 
prefix  for  the  attribute  'ADDRESS  refers  to  an  object  that  has  a  meaningless 
address: 


The  prefix  of  the  'ADDRESS  attribute  denotes  a  program  unit  that 
has  no  meaningful  address:  the  result  of  such  an  evaluation  is 
SYSTEM . NULL. ADDRESS . 

The  following  entities  do  not  have  meaningful  addresses  and  will  cause  the 
above  compilation  warning  if  used  as  a  prefix  to  'ADDRESS: 

■  A  constant  that  is  implemented  as  an  immediate  value  (that  is,  a  constant 
that  does  not  have  any  space  allocated  for  it). 

■  A  package  identifier  that  is  not  a  library  unit  or  a  subunit. 

■  A  function  that  renames  an  enumeration  literal. 

Additionally,  the  attribute  'ADDRESS,  when  applied  to  a  task  or  task  type, 
returns  different  values  depending  on  the  elaboration  status  of  the  task  body. 

In  particular,  the  value  returned  by  the  attribute  'ADDRESS  changes  after 
the  elaboration  of  the  task  body.  Therefore,  the  attribute  tosJk  ’  ADDRESS 
or  task-type’ ADDRESS  should  be  used  only  after  the  body  of  the  task  is 
elaborated . 
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F  2.2  Attribute  SYSTEM.ADDRESS’IMPORT 

This  implementation  of  Ada  defines  an  additional  attribute  for  the  type 
SYSTEM.  ADDRESS.  The  attribute  ’IMPORT  can  be  applied  to  the  type 
SYSTEM .  ADDRESS.  This  attribute  is  a  function  with  two  parameters;  the 
parameters  are  described  in  the  table  below. 


Syntax 

SYSTEM .  ADDRESS  ’  IMPORT  {"Language-name" ,  " extemalsymboLname") ; 


Parameter 

Description 

Language -name 

Specifies  the  language.  This  parameter  is  a  static  Ada 
string  constant  that  must  be  either  C,  ASSEMBLER, 
PASCAL,  or  FORTRAN.  The  characters  used  in  the 
language  specification  can  be  uppercase  or  lowercase 
letters. 

eziernaLsymboLname 

Specifies  the  name  of  an  external  data  object.  This 
parameter  is  a  static  Ada  string  constant. 

The  result  is  a  value  of  the  type  SYSTEM .  ADDRESS  that  can  be  used  to  denote 
this  object  in  an  address  clause  (see  section  “F  6.  Address  Clauses"  for 
details.) 
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The  following  example  shows  the  use  of  SYSTEM .  ADDRESS  ’  IMPORT  in  Ada 
address  clauses  to  provide  Ada  access  to  global  data  objects  declared  in  C. 

C  code: 

/*  This  C  code  declares  a  variety  of  globally  visible  data 

objects  that  can  be  accessed  from  an  Ada  program  that  uses 

SYSTEM . ADDRESS ’ IMPORT . 

*/ 

extern  int  errno; 

struct  •( 
short  fl; 
short  f2; 

}  ada.info  =  {-123,  -456}; 

static  int  ada_data[lO]  =  {12,  S,  55,  7,  31,  45,  4,  2,  88,  0}; 

int  ♦ada.data.ptr  =  {ada.data}; 

struct  { 

int  *al; 
short  a2 ; 

}  ada_info_with_ptr  =  {ada.data,  -789}; 


The  sample  Ada  program  follows. 
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Ada  code: 

with  SYSTEM,  UNCHECKED.CONVERSION; 
package  IMPORT.EXAMPLE  is 

—  Import  a  simple  C  scalar  variable,  in  this  case  errno. 
ERRNO:  INTEGER; 

for  ERRNO  use  at  SYSTEM. ADDRESS ’IMPORT  ("C",  "errno"); 

—  Import  a  C  struct  which  contains  no  pointer  values  as 

—  an  Ada  record  (see  below  for  importing  records  which 

—  contain  pointer  fields).  Note  that  a  representation 

—  specification  is  used  to  guarantee  that  Ada  allocates 

—  the  record  fields  the  same  way  C  allocates  the  struct 

—  fields. 

type  ADA.INFO  is 
record 

fl:  SHORT.INTEGER; 
f2:  SHORT.INTEGER; 
end  record; 

for  ADA.INFO  use 
record 

f 1  at  0  range  0. . 15 ; 
f2  at  2  range  0. . 15; 
end  record; 

AI  :  ADA.INFO; 

for  AI  use  at  SYSTEM. ADDRESS 'IMPORT  ("C".  "ada.info") ; 
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—  Import  a  C  pointer  object  as  an  Ada  access  type.  If 

—  such  a  pointer  was  imported  directly  as  an  Ada  access 

—  type  value  (in  a  manner  similar  to  ERRNO  above),  the 

—  elaboration  code  for  this  declaration  section  would 

—  initialize  the  Ada  access  type  value  to  null,  modifying 

—  the  C  pointer  object.  The  technique  of  renaming  the 

—  dereferenced  result  of  an  unchecked  conversion  prevents 

—  Ada  from  initializing  the  Ada  access  type  value  and 

—  leaves  the  value  that  C  initialized  the  pointer  object 

"  with,  intact.  Of  course  if  you  do  want  Ada  to  initialize 

—  a  non-Ada  pointer  object  to  null,  import  it  directly 

—  similarly  to  the  manner  in  which  ERRNO  is  imported. 

type  ADA.DATA  is  array  (1..10)  of  INTEGER; 

type  ADA_DATA_ACCESS  is  access  ADA.DATA; 

type  ADA.DATA_ACCESS_ACCESS  is  access  ADA_DATA_ACCESS ; 

function  ADDRESS.TO.ADA.DATA. ACCESS. ACCESS  is  new 
UNCHECKED.CONVERSION 

(SYSTEM . ADDRESS ,  ADA.DATA.ACCESS. ACCESS) ; 

ADA  :  ADA.DATA.ACCESS  renames 

ADDRESS.TO.ADA.DATA.ACCESS.ACCESS 
(SYSTEM . ADDRESS ’ IMPORT 

("C",  "ada.data.ptr")) .all; 
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—  Import  a  C  struct  which  contains  a  pointer  value  as  an 

—  Ada  record.  Note  that  a  representation  specification  is 

—  used  to  guarantee  that  Ada  allocates  the  record  fields 

—  the  same  way  C  allocates  the  struct  fields.  If  such  a 

—  record  was  imported  directly  as  an  Ada  record  type  (in  a 
--  manner  similar  to  ADA.INFO  above) ,  the  elaboration  code 

—  for  this  declaration  section  would  initialize  the  Ada 

—  access  type  field  of  the  record  to  null,  modifying  the 

—  C  record  object.  The  technique  of  renaming  the  result  of 

—  an  unchecked  conversion  prevents  Ada  from  initializing 

—  the  Ada  access  type  field  and  leaves  the  value  that  C 

—  initialized  the  record  object  with,  intact.  A  similar 

—  set  of  declarations  can  be  used  to  import  zmy  arbitrary 

—  record  as  protection  against  initializing  any  access  value 

—  fields  it  may  have  (which  could  be  nested  at  any  depth 

—  in  the  record  such  that  they  might  be  accidentally  be 

—  overlooked) .  Of  course  if  you  do  want  Ada  to  initialize 

—  pointer  fields  or  elements  of  a  non-Ada  record  or  array 

—  to  null,  import  the  record  or  array  directly,  similarly 
--  to  the  manner  in  which  ADA.INFO  is  imported. 

type  ADA.INFO.WITH.PTR  is 
record 

al;  ADA.DATA. ACCESS ; 
a2:  SHORT.INTEGER; 
end  record; 
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for  ADA.INFO.WITH.PTR  use 
record 

al  at  0  range  0. .31 ; 
a2  at  4  range  0. .15; 
end  record; 

type  ADA.INFO.WITH.PTR.ACCESS  is  access  ADA.INFO.WITH.PTR; 

function  ADDRESS.TO.ADA.INFO.WITH.PTR.ACCESS  is  new 
UNCHECKED.CONVERSION 

(SYSTEM. ADDRESS.  ADA.INFO.WITH.PTR.ACCESS) ; 

AIWP  :  ADA.INFO.WITH.PTR  renames 

ADDRESS.TO.ADA.INFO.WITH.PTR.ACCESS 
(SYSTEM . ADDRESS ’ IMPORT 

("C",  "ada.info_with.ptr")) .all; 


end  IMPORT.EXAMPLE; 

with  IMPORT.EXAMPLE; 

procedure  USE.IMPORT  (N:  INTEGER)  is 

begin  --  USE.IMPORT 

if  N  <  1  or  else  N  >  10  then 

—  Change  errno  to  a  value  from  the  imported  record. 

IMPORT.EXAMPLE. ERRNO  :«  INTEGER  (IMPORT.EXAMPLE. AI .F2) ; 
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—  Change  vhat  the  C  pointer  points  at  (note  that  this 

—  does  not  change  the  contents  of  the  ada.data  array  in 
—  C,  it  changes  the  array  that  the  C  ada_data_ptr 

—  points  at) . 

IMPORT.EXAMPLE.ADA  :=  new  IMPORT.EXAMPLE.ADA.DATA; 

—  Fill  in  the  new  array 

for  I  in  1 . . 10  loop 

IMPORT.EXAMPLE.ADA  (I)  ;=  I; 
end  loop; 
else 

—  Change  errno  to  a  value  from  the  imported  pointed 

—  to  array . 

IMPORT.EXAMPLE. ERRNO  :=  IMPORT.EXAMPLE.ADA  (N) ; 

—  Change  that  element  of  the  currently  pointed  to  array. 

IMPORT.EXAMPLE.ADA  (K)  :*  INTEGER ( IMPORT.EXAMPLE. AI WP. A2) ; 
end  if ; 

end  USE. IMPORT; 
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F  3.  The  SYSTEM  and  STANDARD  Packages 

This  section  contains  a  complete  listing  of  the  two  predefined  library  packages: 

SYSTEM  and  STANDARD.  These  packages  both  contain  implementation-dependent 
specifications. 

F  3.1  The  Package  SYSTEM 

The  specification  of  the  predefined  library  package  SYSTEM  follows: 
package  SYSTEM  is 

type  NAME  is  (HP9000.PA.RISC)  ; 

SYSTEM.NAME  :  constant  NAME  :=  HPSOOO.PA.RISC; 

STORAGE.UNIT  :  constant  :=  8; 

MEMORY_SIZE  :  constant  :=  2**31-1; 

MIN_INT  :  constant  :=  -  (2**31); 

MAX_INT  :  constant  :=  2**31  -  1; 

MAX.DIGITS  :  constant  :=  15; 

MAX.MANTISSA  :  constant  :=  31; 
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FISE.DELTA  :  constant  ;=  2#1.0«E-3l; 

TICK  :  constant  0.010;  —  10  milliseconds 

subtype  PRIORITY  is  INTEGER  range  1  . .  16; 
type  ADDRESS  is  private ; 

NULL.ADDRESS  :  constant  ADDRESS;  —  set  to  NULL 


--  The  functions  TO.INTEGER  and  TO.ADDRESS  are  provided  for 
—  backwards  compatibility  with  Ada/800  04.35 


function  TO. INTEGER  (LEFT  :  ADDRESS)  return  INTEGER; 


—  Converts  an  ADDRESS  to  and  INTEGER. 


function  TO.ADDRESS  (LEFT  :  INTEGER)  return  ADDRESS; 


—  Converts  and  INTEGER  to  an  ADDRESS. 


function  VALUE  (LEFT  :  in  STRING)  return  ADDRESS; 


—  Converts  a  string  to  an  address.  The  string  can  represent 

—  either  an  unsigned  address  (i.e.  "16#XXXXXXXX#"  where 

--  XXXXXXXX  is  in  the  range  0..FFFFFFFF)  or  a  signed  address 
--  (i.e.  "-16#XXXXXXXX#"  where  XXXXXXXX  is  in  the 

—  range  0. .7FFFFFFF) .  Leading  blanks  are  ignored.  The 

—  exception  CONSTRAINT.ERROR  is  raised  if  the  string  has 

—  hot  the  proper  syntax. 


3-2  F  3.  The  SYSTEM  and  STANDARD  Packages 


ADDRESS. WIDTH  :  constant  :=  3  ♦  8  +  1; 

subtype  ADDRESS.STRING  is  STRING(1.  .ADDRESS. WIDTH)  ; 

function  IMAGE  (LEFT  :  in  ADDRESS)  return  ADDRESS.STRING; 


"  Converts  an  address  to  a  string.  The  returned  string  has 

—  the  xinsigned  representation  described  for  the  VALUE 

—  function. 
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type  OFFSET  is  range  -2**31  .  .  2**31-1; 


—  This  type  is  used  to  measure  a  number  of  storage  units 

—  (bytes).  The  type  is  an  Ada  integer  type. 


function  SAME.SPACE.ID 

(LEFT,  RIGHT  :  in  ADDRESS)  return  BOOLEAN; 


—  This  function  returns  true  if  the  two  addresses  have  the 

—  same  space  id. 


ADDRESS.ERROR  :  exception; 


—  This  exception  is  raised  by  and 

—  (with  two  ADDRESS  operands)  if  the  two  addresses  do  not 

—  have  the  same  space  id.  The  exception  CONSTRAINT.ERROR 

—  can  be  raised  by  and  if  the  result  of  ADDRESS  does 

—  not  have  the  same  space  id  as  the  ADDRESS  operand. 
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function  "+"  (LEFT  :  in  ADDRESS;  RIGHT  :  in  OFFSET) 
return  ADDRESS ; 

function  "+"  (LEFT  :  in  OFFSET;  RIGHT  :  in  ADDRESS) 
return  ADDRESS ; 

function"-"  (LEFT  :  in  ADDRESS;  RIGHT  :  in  OFFSET) 
return  ADDRESS; 


—  These  routines  provide  support  for  address  computations. 

—  The  meaning  of  the  "+"  and  operators  is  architecture 

—  dependent.  For  the  HP  9000/PA-RISC  consider  the  ADDRESS 

—  parameter  to  be  the  address  of  the  first  byte,  of  an  eirray 

—  of  contiguous  bytes,  that  grows  from  lower  toward  higher 

—  (in  an  unsigned  sense)  memory  addresses. 

—  The  "+"  function  returns  the  address  of  the  byte  at  offset 

—  OFFSET  in  the  ADDRESS  array .  In  C  syntax  it  returns : 

&(((char  *)  ADDRESS) [OFFSET]) 

"  The  function  returns  the  address  of  the  byte  at  offset 
--  -OFFSET  in  the  ADDRESS  array.  In  C  syntax  it  returns: 
&(((char  *)  ADDRESS) [-OFFSET] ) 


function"-"  (LEFT  ;  in  ADDRESS;  RIGHT  :  in  ADDRESS) 
return  OFFSET; 


—  Returns  the  distance  between  the  given  addresses.  The 

—  result  is  signed. 
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function  "<="  (LEFT.  RIGHT  :  in  ADDRESS)  return  BOOLEAN ; 

function  "<"  (LEFT,  RIGHT  :  in  ADDRESS)  return  BOOLEAN; 

function  ">="  (LEFT.  RIGHT  :  in  ADDRESS)  return  BOOLEAN ; 

function  ">"  (LEFT.  RIGHT  :  in  ADDRESS)  return  BOOLEAN; 


—  Perform  a  comparison  on  addresses.  The  comparison 

—  is  imsigned. 


function  "mod"  (LEFT  :  in  ADDRESS;  RIGHT  :  in  POSITIVE) 
return  NATURAL; 


—  Returns  the  offset  of  LEFT  relative  to  the  memory  block 

—  immediately  below  it  starting  at  a  multiple  of  RIGHT 

—  storage  units . 


type  ROUND.DIRECTION  is  (DOWN,  UP)  ; 

function  ROUND  (VALUE  ;  in  ADDRESS; 

DIRECTION  :  in  ROUND.DIRECTION; 

MODULUS  :  in  POSITIVE)  return  ADDRESS; 


—  Returns  the  given  address  rounded  to  a  specific  value. 
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—  The  functions  ALIGN,  ALIGN  and  IS.ALIGNED  are  provided  for 

—  backwards  compatibility  with  Ada/800  04.35 


function  ALIGN  (LEFT  :  ADDRESS)  return  ADDRESS; 


—  Align  the  given  address  up  to  four  bytes  boundary 

—  (equivalent  to  SYSTEM. ROUND  (LEFT,  SYSTEM. UP,  4):) 


function  ALIGN  (LEFT  :  ADDRESS;  ALIGNMENT  :  INTEGER) 
return  ADDRESS; 


—  Align  the  given  address  up  to  the  alignment  boundary  if  the 

—  alignment  is  positive  (equivalent  to 

—  SYSTEM. ROUND  (LEFT,  SYSTEM. UP,  POSITIVE  (ALIGNMENT));). 

—  Align  the  given  address  down  to  the  alignment  boundary  if 

—  the  alignment  is  negative  (equivalent  to 

—  SYSTEM. ROUND  (LEFT,  SYSTEM. DOWN,  POSITIVE  (-ALIGNMENT));). 


function  IS.ALIGNED  (LEFT  :  ADDRESS;  ALIGNMENT  :  POSITIVE) 
return  BOOLEAN ; 


—  Returns  TRUE  if  the  LEFT  is  aligned  at  the  ALIGNMENT 

—  boundary  (equivalent  to 

—  SYSTEM. "mod"  (LEFT,  ALIGNMENT)  =  0). 
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generic 

type  TARGET  is  private ; 

function  FETCH.FROM.ADDRESS  (A  :  in  ADDRESS) 
return  TARGET ; 


—  Return  the  bit  pattern  stored  at  address  A,  as  a  value  of 

—  the  specified  TARGET  type. 

—  WARNING:  These  routines  may  give  unexpected  results  if  used 

—  with  unconstrained  types . 


generic 

type  TARGET  is  private; 
procedure  ASSIGN_TO_ADDRESS 

(A  :  in  ADDRESS;  T  :  in  TARGET) ; 


—  Store  the  bit  pattern  representing  the  value  of  the 

—  specified  TARGET  object,  into  address  A. 

—  WARNING:  These  routines  may  give  unexpected  results  if  used 

—  with  unconstrained  types . 


type  OBJECT.LENGTH  is  range  0  . .  2**31  -1 ; 


—  This  type  is  used  to  designate  the  size  of  an  object  in 

—  storage  units. 
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procedure  MOVE  (TO  ;  in  ADDRESS; 
FROM  :  in  ADDRESS; 

LENGTH  :  in  OBJECT.LENGTH)  ; 


—  Copies  LENGTH  storage  units  starting  at  the  address  FROM 

—  to  the  address  TO.  The  source  and  destination  may  overlap. 

—  Use  of  this  procedure  in  optimized  code  may  lead  to 

—  unexpected  results. 


—  Exported  subprogram  types,  exceptions,  and  functions. 

type  EXPORTED.SUBPROGRAM. ADDRESS  is  new  INTEGER; 

NOT.EXPORTED.SUBPROGRAM  ;  exception; 

function  EXPORTED.SUBPROGRAM  (ADA.ADDRESS  :  in  ADDRESS) 
return  EXPORTED.SUBPROGRAM.ADDRESS ; 
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—  When  the  parameter  ADA.ADDRESS  is  passed  the  ’ADDRESS  of 

—  an  Ada  subprogram  which  has  been  exported  via  pragma  EXPORT, 

—  the  function  returns  as  a  result,  the  "address"  which  must 

—  be  called  by  non- Ada  code  to  invoke  that  Ada  subprogram. 

—  Note  that  the  address  provided  by  ’ADDRESS  must  NOT  be 

—  called  directly  by  non-Ada  code  to  invoke  an  exported  Ada 

—  subprogram  (the  result  of  doing  so  is  unpredictable  and  will 

—  most  probably  result  in  program  failure) .  The  result  of 
--  this  fimction  must  always  be  used  as  the  address  to  be 
--  called  by  non-Ada  code.  If  ADA.ADDRESS  is  not  the 

--  ’ADDRESS  of  an  exported  Ada  subprogram,  the  function  will 

—  raise  the  exception  NOT_EXPORTED_SUBPROGRAH. 


private 

—  private  part  of  package  SYSTEM 
end  SYSTEM; 
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F  3.2  The  Package  STANDARD 

The  specification  of  the  predefined  library  package  STANDARD  follows; 
package  STANDARD  is 

—  The  operators  that  are  predefined  for  the  types  declared 

—  in  this  package  are  given  in  coments  since  they  are 

”  implicitly  declared.  Italics  are  used  for  pseudo-names 

—  of  anonymous  t3rpes  (such  as  universal_real , 

—  universal.integer ,  and  universal^f ixed)  and  for  \indefined 

—  information  (such  as  any.f ixed.point.type) . 

—  Predefined  type  BOOLEAN 
type  BOOLEAN  is  (FALSE,  TRUE) ; 

—  The  predefined  relational  operators  for  this  type  are 
--  as  follows  (these  are  implicitly  declared); 

—  function"*"  (LEFT.  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

—  function"/*"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

--  function  "<"  (LEFT.  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

—  function  "<*"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN ; 

—  function  ">"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

—  function  ">="  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN ; 

—  The  predefined  logical  operands  and  the  predefined 

—  logical  negation  operator  are  as  follows  (these  are 

—  implicitly  declared) : 

—  function  "and"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

—  function  "or"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN ; 

—  function  "xor"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

—  function  "not"  (RIGHT  ;  BOOLEAN)  return  BOOLEAN; 
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—  Predefined  imiversal  types 


—  type  universal. integer  is  predefined; 

—  The  predefined  operators  for  the  type  universal. integer 

—  are  as  follows  (these  are  implicitly  declared) : 

—  function"*"  (LEFT,  RIGHT  :  universal. integer) 

—  return  BOOLEAN ; 

—  function  "/*"  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN ; 

—  function  "<"  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN ; 

—  function  "<*"  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN ; 

—  function  ">"  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN ; 

—  function  ">*"  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN ; 

—  function  "+"  (RIGHT  :  universal.integer) 

—  return  universal.integer; 

—  function  (RIGHT  :  universal.integer) 

—  return  universal.integer; 

--  function  "abs"  (RIGHT  :  universal.integer) 

—  return  universal.integer; 

—  function  "+"  (LEFT,  RIGHT  :  universal.integer) 

—  return  universal.integer; 

—  function  (LEFT,  RIGHT  :  universal.integer) 

—  return  universal.integer; 

—  function  (LEFT,  RIGHT  :  universal.integer) 

—  return  universal.integer; 

—  function  (LEFT,  RIGHT  :  universal.integer) 

--  return  universal.integer; 
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-r  function  "rem"  (LEFT,  RIGHT  :  universal.integer) 

—  return  tmiversal.integer ; 

—  function  "mod"  (LEFT,  RIGHT  :  universal.integer) 

—  return  universal.integer ; 

—  function  "♦*"  (LEFT  :  universal.integer; 

RIGHT  :  INTEGER)  return  universal.integer 

—  type  universal.real  is  predefined; 

"  The  predefined  operators  for  the  type  universal.real 
"  are  as  follows  (these  are  implicitly  declared): 

—  function  (LEFT,  RIGHT  ;  universal.integer) 

—  return  BOOLEAN ; 

—  function  "/="  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN; 

—  function  "<"  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN; 

—  function  "<*"  (LEFT,  RIGHT  :  universal.integer) 

—  return  BOOLEAN ; 

--  function  ">"  (LEFT,  RIGHT  :  tiniversal. integer) 

—  return  BOOLEAN ; 

"  function  ">="  (LEFT,  RIGHT  ;  universal.integer) 

—  return  BOOLEAN ; 

—  function  (RIGHT  :  universal.integer) 

--  return  universal. integer; 

"  function  (RIGHT  :  universal.integer) 

—  return  universal.integer; 

--  function  "abs"  (RIGHT  :  universal.integer) 

—  return  universal.integer; 

—  function  "+"  (LEFT,  RIGHT  :  universal.integer) 

—  return  universal.integer; 
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function  (LEFT,  RIGHT  :  universal  .integer) 

return  universal. integer; 

function  (LEFT,  RIGHT  :  universal.integer) 

return  tiniversal.integer; 

function  (LEFT,  RIGHT  :  universal.integer) 

return  universal.integer; 

function  "**"  (LEFT  :  universal.real ; 

RIGHT  :  INTEGER)  return  universal.real ; 
In  addition,  the  following  operators  are 
predefined  for  universal  types: 

function  (LEFT  :  universal.integer; 

RIGHT  :  universal.real) 
return  universal.real 
function  (LEFT  :  universal.real; 

RIGHT  ;  universal.integer) 
return  universal,  real  ; 
function  (LEFT  :  xmiversal.real ; 

RIGHT  :  universal.integer) 
return  universal.real; 

type  universal.f ixed  is  predefined; 

The  only  operators  declared  for  this  type  are: 
function  (LEFT  :  any.f ixed.point.type ; 

RIGHT  :  any.f ixed.point.type) 
return  universal.f  ixed; 

function  "/"  (LEFT  :  any.f  ixed.point.type; 

RIGHT  :  any.f ixed.point.type) 
return  universal.f  ixed; 
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—  Predefined  aaid  additional  integer  types 

type  SHORT_SHORT_INTEGER  is  range -128  ..  127;  —8  bits  long 

—  This  is  equivalent  to  -(2**7)  ..  (2**7)-l 

—  The  predefined  operators  for  this  type  are  as  follows 

—  (these  are  implicitly  declared): 

—  function  '•*"  (LEFT.  RIGHT  :  SHORT.SHORT. INTEGER) 

—  return  BOOLEAN ; 

—  function  "/*"  (LEFT.  RIGHT  :  SHORT.SHORT.INTEGER) 

—  return  BOOLEAN ; 

“  function  "<"  (LEFT.  RIGHT  :  SHORT.SHORT.INTEGER) 

—  return  BOOLEAN ; 

"  function  "<*"  (LEFT.  RIGHT  :  SHORT.SHORT.INTEGER) 

—  return  BOOLEAN ; 

—  function  ">"  (LEFT,  RIGHT  :  SHORT.SHORT.INTEGER) 

—  return  BOOLEAN ; 

—  function  ">="  (LEFT,  RIGHT  :  SHORT.SHORT.INTEGER) 

—  return  BOOLEAN ; 

—  function  "+"  (RIGHT  :  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER: 

—  function  (RIGHT  :  SHORT.SHORT.INTEGER) 

"  return  SHORT.SHORT.INTEGER; 

—  function  "abs"  (RIGHT  :  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER; 

—  function  "+"  (LEFT, RIGHT:  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER; 

—  function  (LEFT, RIGHT:  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER; 

“  function  "*"  (LEFT.RIGHT:  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER; 

—  function  (LEFT.RIGHT:  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER: 
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—  function  "rem"  (LEFT, RIGHT:  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER: 

—  function  "mod"  (LEFT, RIGHT:  SHORT.SHORT.INTEGER) 

—  return  SHORT.SHORT.INTEGER: 


—  function  "**"  (LEFT  :  SHORT.SHORT.INTEGER: 

RIGHT  :  INTEGER)  return  SHORT.SHORT.INTEGER: 


type  SHORT.  INTEGER  is  range -32.768  ..  32.767:  —16  bits  long 


—  This  is  equivalent  to  -(2**15)  ..  (2**15)-1 

—  The  predefined  operators  for  this  type  are  as  follows 

—  (these  are  implicitly  declared) : 

—  function  "="  (LEFT,  RIGHT  :  SHORT.INTEGER)  return  BOOLEAN 

—  function  "/="  (LEFT,  RIGHT  :  SHORT.INTEGER)  return  BOOLEAN 

—  function  "<"  (LEFT,  RIGHT  :  SHORT.INTEGER)  return  BOOLEAN 

—  function  "<="  (LEFT,  RIGHT  :  SHORT.INTEGER)  return  BOOLEAN 

—  function  ">"  (LEFT,  RIGHT  :  SHORT.INTEGER)  return  BOOLEAN 

—  function  ">*"  (LEFT,  RIGHT  :  SHORT.INTEGER)  return  BOOLEAN 


--  function  (RIGHT  :  SHORT.INTEGER)  return  SHORT.INTEGER 

—  function  (RIGHT  ;  SHORT.INTEGER)  return  SHORT.INTEGER 

—  function  "abs" (RIGHT  :  SHORT.INTEGER)  return  SHORT.INTEGER 

—  function  (LEFT,  RIGHT  ;  SHORT.INTEGER) 

—  return  SHORT.INTEGER: 

—  function  "-"  (LEFT,  RIGHT  :  SHORT.INTEGER) 

—  return  SHORT.INTEGER: 

—  function"*"  (LEFT,  RIGHT  :  SHORT.INTEGER) 

—  return  SHORT.INTEGER: 

—  function"/"  (LEFT,  RIGHT  :  SHORT.INTEGER) 

—  return  SHORT.INTEGER; 
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—  function  "rem"  (LEFT,  RIGHT  :  SHORT. INTEGER) 

—  return  SHORT. INTEGER; 

—  function  "mod"  (LEFT.  RIGHT  :  SHORT. INTEGER) 

—  return  SHORT. INTEGER; 

—  function  "**"  (LEFT  :  SHORT.INTEGER; 

RIGHT  :  INTEGER)  return  SHORT.INTEGER; 

type  INTEGER  is  range  -2.147.483.648  . .  2.147.483.647; 

—  type  INTEGER  is  32  bits  long 

—  This  is  equivalent  to  -(2**31)  ..  (2**3l)-l 

—  The  predefined  operators  for  this  type  are  as  follows 

—  (these  are  implicitly  declared) : 

—  function  "="  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN ; 

—  function"/*"  (LEFT.  RIGHT  :  INTEGER)  return  BOOLEAN; 

—  function  "<"  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

—  function  "<*"  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

—  function  ">"  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

—  function  ">*"  (LEFT,  RIGHT  :  INTEGER)  return  BOOLEAN; 

—  function  (RIGHT  :  INTEGER)  return  INTEGER; 

—  function  "-"  (RIGHT  :  INTEGER)  return  INTEGER; 

—  function  "abs"  (RIGHT  :  INTEGER)  return  INTEGER; 

—  function  (LEFT,  RIGHT  :  INTEGER)  return  INTEGER; 

—  function  "-"  (LEFT.  RIGHT  :  INTEGER)  return  INTEGER; 

—  function  "*"  (LEFT.  RIGHT  :  INTEGER)  return  INTEGER; 

—  function  (LEFT,  RIGHT  :  INTEGER)  return  INTEGER; 

—  function  "rem"  (LEFT,  RIGHT  :  INTEGER)  return  INTEGER; 

—  function  "mod"-  (LEFT,  RIGHT  :  INTEGER)  return  INTEGER; 

—  function  "**"  (LEFT  :  INTEGER;  RIGHT  :  INTEGER) 

—  return  INTEGER; 
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—  Predefined  INTEGER  subtypes 

subtype  NATURAL  is  INTEGER  range  0  ..  INTEGER  ’  LAST ; 
subtype  POSITIVE  is  INTEGER  range  1  ..  INTEGER ’LAST; 

—  Predefined  and  additional  floating  point  types 
type  FLOAT  is  digits  6  range  —  32  bits  long 

2#1.111_1111. 1111. 1111. 1111_1111#E+127; 

—  This  is  equivalent  to  -(2.0  -  2.0**(-23))  *  2.0**127  .. 

♦(2.0  -  2.0**(-23))  *  2.0**127 

—  This  is  approximately  equal  to  the  decimal  range: 

—  -3.402823E+38  ..  +3 .402823E+38 

—  The  predefined  operators  for  this  type  aure  as  follows 

—  (these  are  implicitly  declared): 

—  function"*"  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

—  function  "/*"  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

—  function  "<"  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

—  function  "<*"  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

—  function  ">"  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

—  function  ">="  (LEFT,  RIGHT  :  FLOAT)  return  BOOLEAN; 

—  fun^ion  "♦"  (RIGHT  :  FLOAT)  return  FLOAT; 

—  function  "-"  (RIGHT  :  FLOAT)  return  FLOAT; 

—  function  "abs"  (RIGHT  :  FLOAT)  return  FLOAT; 

—  function  "+"  (LEFT,  RIGHT  :  FLOAT)  return  FLOAT; 

—  function  (LEFT,  RIGHT  :  FLOAT)  return  FLOAT; 

—  function  "*"  (LEFT,  RIGHT  ;  FLOAT)  return  FLOAT; 

—  function"/"  (LEFT,  RIGHT  :  FLOAT)  return  FLOAT; 

—  function  "**"  (LEFT  :  FLOAT;  RIGHT  :  INTEGER)  return  FLOAT; 
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type  LONG.FLOAT  b  digits  15  range  —  64  bits  long 

—  Note:  the  following  ranges  are  intentionally  split 

over  two  lines. 

"  In  actual  Ada  programs,  the  values  must  be  on  one  line. 

—  This  is  equivalent  to  -(2.0  -  2.0**(-52))  *  2.0**1023  .. 

♦(2.0  -  2.0**(-52))  *  2.0**1023  .. 

—  This  is  approximately  equal  to  the  decimal  range; 

- 1. 7976931348623 15E+308  +1 .797693134862315E+308 


The  predefined  operators  for  this  type  are  as  follows 
(these  are  implicitly  declared) : 


—  function 

—  function  "/*" 

—  function  "<" 

—  function  "<*" 
"  function  ">" 

—  function  ">=" 

—  function  "♦" 

—  function 

—  function 


(LEFT.  RIGHT  :  LONG.FLOAT)  return  BOOLEAN; 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  BOOLEAN; 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  BOOLEAN; 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  BOOLEAN; 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  BOOLEAN; 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  BOOLEAN; 
(RIGHT  :  LONG.FLOAT)  return  LONG.FLOAT; 
(RIGHT  :  LONG.FLOAT)  return  LONG.FLOAT: 


abs"  (RIGHT  :  LONG.FLOAT)  return  LONG.FLOAT 


—  function  "♦ 


—  function 
"  function  "*" 
“  function 


(LEFT,  RIGHT  :  LONG.FLOAT)  return  LONG.FLOAT 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  LONG.FLOAT 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  LONG.FLOAT 
(LEFT,  RIGHT  :  LONG.FLOAT)  return  LONG.FLOAT 


—  function  "**"  (LEFT  :  LONG.FLOAT;  RIGHT  :  INTEGER) 
return  LONG.FLOAT 
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— This  implementation  does  not  provide  any  other 
— floating  point  types 

—  Predefined  type  DURATION 

type  DURATION  is  delta  2#0.000_000_000_000.01# 
range -86_400.0  ..  86_400.0; 

—  DURATION ’SMALL  derived  from  this  delta  is  2.0**(-14), 

—  which  is  the  maximum  precision  that  an  object  of  type 

—  DURATION  can  have  and  still  be  representable  in  this 

—  implementation.  This  has  an  approximate  decimal  equivalent 

—  of  0.000061  (61  microseconds).  The  predefined  operators 

—  for  the  type  DURATION  are  the  same  as  for  any 

—  fixed  point  type. 

—  This  implementation  provides  many  anonymous  predefined 

—  fixed  point  types.  They  consist  of  fixed  point  types 

—  whose  "small"  value  is  a  power  of  2.0  and  whose  mantissa 

—  can  be  expressed  using  31  or  less  binary  digits. 

—  Predefined  type  CHARACTER 

—  The  following  lists  characters  for  the  standard  ASCII 

—  character  set.  Character  literals  corresponding  to 

—  cohtrol  characters  are  not  identifiers;  they  eure 

—  indicated  in  italics  in  this  section. 

type  CHARACTER  is 

(  mil,  soh,  six,  etx,  eot,  enq,  ack,  bel, 
bs,  hi.  If,  vt,  ff,  cr.  so,  si, 
die,  del,  dc2,  dcS,  dc4,  nak,  syn,  cth, 
can,  em,  sub,  esc,  fs,  gs,  rs,  vs. 
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>  1 

’  1  > 

» 

>  II  > 

» 

•y.\ 

>  >  9 

t  i 
$  $ 

}  •  ’ 

• 

>  ) 

'O’, 

*2’, 

’3‘, 

’4', 

’5», 

‘6’, 

,7, 

’8», 

’9’. 

> .  > 

>  •  1 

1  » 

»  =  » 

• 

>?» 

’A’, 

’B’, 

’C‘, 

’D>, 

’E>. 

»F', 

»G» 

’H>, 

'I*. 

’J’ , 

’K*, 

’L’ , 

’H*, 

’N‘, 

♦o» 

’P’. 

’Q’. 

'R’, 

’S«, 

’U». 

‘V, 

•W’ 

’X*, 

’Y«, 

’Z' , 

» 

f  > 

1  (  1 

» 

’a’ , 

’b’ , 

’c‘. 

’d'. 

•e’. 

’f  ’ . 

’g’ 

’h>. 

’i’ . 

’j’. 

’k’. 

’1’. 

’m’ , 

’n». 

’o’ 

’P’. 

’q’. 

*r' , 

’s* , 

’t*. 

’u». 

*v’ , 

’w’ 

’X’. 

’y’. 

’2’  . 

’I‘. 

0 

del) 

— The  predefined  operators  for  the  type  CHARACTER  are 
— the  same  as  for  any  enumeration  type. 

—  Predefined  type  STRING  (RM  3.6.3) 

type  STRING  is  array  (POSITIVE  range  <»  of  CHARACTER; 

—  The  predefined  operators  for  this  type  are  as  follows 

—  function"*"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 

—  function"/*"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN ; 

—  function  "<"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 

—  function  "<*"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 

—  function  ">"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN ; 

—  function  ">*"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 
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—  Predefined  catenation  operators 

"  function  "ft"  (LEFT  :  STRING;  RIGHT  :  STRING) 
return  STRING ; 

—  function  "ft"  (LEFT  :  CHARACTER;  RIGHT  :  STRING) 
return  STRING ; 

"  function  "ft"  (LEFT  :  STRING;  RIGHT  :  CHARACTER) 
return  STRING; 

—  function  "ft"  (LEFT  :  CHARACTER;  RIGHT  :  CHARACTER) 
return  STRING; 


—  Predefined  exceptions 
CONSTRAINT.ERROR  :  exception; 
NUMERIC.ERROR  :  exception; 
PROGRAH.ERROR  :  exception; 
STORAGE.ERROR  :  exception ; 
TASKING.ERROR  :  exception; 

—  Predefined  package  ASCII 
package  ASCII  is 

—  Control  characters 
NUL  :  constant  CHARACTER 
SOH  ;  constant  CHARACTER 
STX  :  constant  CHARACTER 
ETX  :  constant  CHARACTER 
EOT  :  constant  CHARACTER 
ENQ  :  constant  CHARACTER 
ACK  :  constant  CHARACTER 
BEL  :  constant  CHARACTER 
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BS 

constant  CHARACTER 

«  bs; 

HT 

constant  CHARACTER 

^hf. 

LF 

constant  CHARACTER 

-If: 

VT 

constant  CHARACTER 

-  vt; 

FF 

constant  CHARACTER 

-  S: 

CR 

constant  CHARACTER 

=  cr; 

SO 

constant  CHARACTER 

*  so; 

SI 

constant  CHARACTER 

e  si; 

DLE 

constant  CHARACTER 

=  die; 

DCl 

constant  CHARACTER 

=  del; 

DC2 

constant  CHARACTER 

11 

DC3 

constant  CHARACTER 

*  dcS; 

DC4 

constant  CHARACTER 

=  dc4; 

NAK 

constant  CHARACTER 

=  nak; 

SYN 

constant  CHARACTER 

*  syn; 

ETB 

constant  CHARACTER 

*  etb; 

CAN 

constant  CHARACTER 

=  can; 

EM 

constant  CHARACTER 

-  em; 

SUB 

constant  CHARACTER 

»  sub; 

ESC 

constant  CHARACTER 

=  esc; 

FS 

constant  CHARACTER 

=  /5: 

GS 

constant  CHARACTER 

=  gs; 

RS 

constant  CHARACTER 

=  rs; 

US 

constant  CHARACTER 

-  us; 

DEL 

constant  CHARACTER 

«  del; 

—  other  characters 


EXCLAN 

QUOTATION 

SHARP 

DOLLAR 

PERCENT 

AMPERSAND 

COLON 


:  constant  CHARACTER 
:  constant  CHARACTER 
:  constant  CHARACTER 
:  constant  CHARACTER 
:  constant  CHARACTER 
:  constant  CHARACTER 
:  constant  CHARACTER 


•  $ 


’S’; 
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SEMICOLON 

constant  CHARACTER 

—  , 
”  t  * 

QUERY 

constant  CHARACTER 

— 

-  ’9 

AT.SIGN 

constant  CHARACTER 

= 

L.BRACKET 

constant  CHARACTER 

=  T: 

BACK.SLASH 

constant  CHARACTER 

=  A’; 

R.BRACKET 

constant  CHARACTER 

=  T; 

CIRCUMFLEX 

constant  CHARACTER 

UNDERLINE 

constant  CHARACTER 

GRAVE 

constant  CHARACTER 

“  > 

L.BRACE 

constant  CHARACTER 

BAR 

constant  CHARACTER 

=  T; 

R.BRACE 

constant  CHARACTER 

TILDE 

constant  CHARACTER 

“  > 

—  Lower  case  letters 
LC.A  :  constant  CHARACTER  ;=  ’a’ 
LC.B  ;  constant  CHARACTER  :=  ’b’ 
LC.C  ;  constant  CHARACTER  :=  'c* 
LC_D  :  constant  CHARACTER  :»  ’d' 
LC.E  :  constant  CHARACTER  :*  ’e’ 
LC.F  ;  constant  CHARACTER  :*  ’f’ 
LC.G  :  constant  CHARACTER  :*  ’g’ 
LC.H  ;  constant  CHARACTER  :=  ’h’ 
LC_I  :  constant  CHARACTER  ;=  ’i’ 
LC.J'  :  constant  CHARACTER  :=  ’j’ 
LC.K  :  constant  CHARACTER  :=  ’k’ 
LC.L  ;  constant  CHARACTER  :=  ’1’ 
LC_M  ;  constant  CHARACTER  :=  ’m’ 
LC_N  ;  constant  CHARACTER  ;=  ’n’ 
LC_0  ;  constant  CHARACTER  :=  ’o’ 
LC.P  :  constant  CHARACTER  :=  ’p’ 
LC.Q  ;  constant  CHARACTER  ;=  ’q’ 
LC_R  :  constant  CHARACTER  :=  ’r’ 
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.  LC_S  :  constant  CHARACTER  :=  *s’ 
LC.T  :  constant  CHARACTER  :=  't' 
LC.U  :  constant  CHARACTER  :=  ‘u’ 
LC_V  :  constant  CHARACTER  :=  'v* 
LC.W  :  constant  CHARACTER  :=  ‘w’ 
LC.X  :  constant  CHARACTER  :=  'x’ 
LC.Y  :  constant  CHARACTER  :=  ‘y’ 
LC.Z  :  constant  CHARACTER  ;=  '2» 

end  ASCII ; 
end  STANDARD; 
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F  4.  Type  Representation 


This  chapter  explains  how  data  objects  are  represented  and  allocated  by  the 
HP  Ada  compiler  for  the  HP  9000  Series  600,  700,  and  800  Computer  Systems 
and  how  to  control  this  using  representation  clauses. 

The  representation  of  a  data  object  is  closely  connected  with  its  type. 
Therefore,  this  section  successively  describes  the  representation  of  enumeration, 
integer,  floating  point,  fixed  point,  access,  task,  array,  and  record  types. 

For  each  class  of  type,  the  representation  of  the  corresponding  data  object 
is  described.  Except  for  array  and  record  types,  the  description  for  each 
class  of  type  is  independent  of  the  others.  Because  array  and  record  types 
are  composite  types,  it  is  necessary  to  understand  the  representation  of  their 
components. 

Ada  provides  several  methods  to  control  the  layout  and  size  of  data  objects; 
these  methods  are  listed  in  Table  4-1. 


Table  4-1.  Methods  to  Control  Layout  and  Size  of  Data  Objects 


Method 

Type  Used  On 

pragma  PACK 

array 

pragma  IMPROVE 

record 

enumeration  representation  clause 

enumeration 

record  representation  clause 

record 

size  specification  clause 

any  type 
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F  4.1  Enumeration  Types 


Syntax  (Enumeration  representation  clause) 
for  enumeration-type-name  use  aggregate; 


The  aggregate  used  to  specify  this  mapping  is  written  as  a  one-dimensional 
aggregate,  for  which  the  index  subtype  is  the  enumeration  type  and  the 
component  type  is  universaLinteger.  An  others  choice  is  not  permitted  in  this 
aggregate. 

F  4.1.1  Internal  Codes  of  Enumeration  Literals 

When  no  enumeration  representation  clause  applies  to  an  enumeration  type, 
the  internal  code  associated  with  an  enumeration  literal  is  the  position  number 
of  the  enumeration  literal.  Thus,  for  an  enumeration  type  with  n  elements,  the 
internal  codes  are  the  integers  0,  1,  2,  ..  ,  n-1. 

An  enumeration  representation  clause  can  be  provided  to  specify  the  value  of 
each  internal  code  as  described  in  the  Ada  RM,  section  13.3.  The  values  used 
to  specify  the  internal  codes  must  be  in  the  range  -(2**31)  to  (2**31)-1. 

The  following  example  illustrates  the  use  of  an  enumeration  representation 
clause. 
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Example 

type  COLOR  is  (RED.  ORANGE,  YELLOW.  GREEN,  AQUA,  BLUE,  VIOLET); 
for  COLOR  use 


(RED 

=> 

10. 

ORANGE 

=> 

20. 

YELLOW 

S> 

40. 

GREEN 

S> 

80. 

AQUA 

=> 

160, 

BLUE 

=> 

320, 

VIOLET 

=> 

640); 

In  the  above  example,  the  internal  representation  for  GREEN  will  be  the 
integer  80.  The  attributes  'FRED  and  'SUCC  will  still  return  YELLOW  and 
AQUA,  respectively.  Also,  section  13.3(6)  in  the  Ada  RM  slates  that  the  ’POS 
attribute  will  still  return  the  positional  value  of  the  enumeration  literal.  In  the 
case  of  GREEN,  the  value  that  *P0S  returns  will  be  3  and  not  80.  The  only  way 
to  examine  the  internal  representation  of  the  enumeration  literal  is  to  write  the 
value  to  a  file  or  use  UNCHECKED.CONVERSION  to  examine  the  value  in  memory. 


F  4.  Type  Representation  4-3 


F  4.1.2  Minimum  Size  of  an  Enumeration  Type  or  Subtype 

The  minimum  size  of  an  enumeration  subtype  is  the  minimum  number  of  bits 
necessary  for  representing  the  internal  codes  in  normal  binary  form. 

A  static  subtype  of  a  null  range  has  a  minimum  size  of  one.  Otherwise,  define 
m  and  M  to  be  the  smallest  and  largest  values  for  the  internal  codes  values  of 
the  subtype.  The  minimum  size  L  is  determined  as  follows: 


Value  of  m 

Calculation  of  L  • 
smallest  positive  integer  such  that: 

Representation 

m  >  0 

M  <2^  -1 

Unsigned 

m  <  0 

-2^-^  <mand  Af  <  -  1 

Signed  two’s  complement 

Example 

type  COLOR  is  (RED,  ORANGE,  YELLOW,  GREEN,  AQUA,  BLUE,  VIOLET); 
—  The  minimxun  size  of  COLOR  is  3  bits. 

subtype  SUNNY.COLOR  is  COLOR  range  ORANGE  ..  YELLOW; 

—  The  minimum  size  of  COLOR  is  2  bits. 

—  because  the  internal  code  for  YELLOW  is  2 

—  and  (2**1)-:1  <=  2  <=  (2**2)-l 

type  TEMPERATURE  is  (FREEZING,  COLD,  MILD,  WARM,  HOT); 
for  TEMPERATURE  use 

(FREEZING  *>  -10, 

COLD  =>  0, 

MILD  =>  10, 

WARM  =>  20, 

HOT  =>  30); 

—  The  minimum  size  of  TEMPERATURE  is  6  bits 

—  because  with  six  bits  we  can  represent  signed 

—  integers  between  -32  and  31 . 
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F  4.1.3  Size  of  an  Enumeration  Type 

When  no  size  specification  is  applied  to  an  enumeration  type,  the  objects  of 
that  type  are  represented  as  signed  machine  integers.  The  HP  9000  Series 
600,  700,  and  800  Computer  Systems  provides  8-,  16-,  and  32-bit  integers,  and 
the  compiler  automatically  selects  the  smallest  signed  machine  integer  that 
can  hold  all  of  the  internal  codes  of  the  enumeration  type.  Thus,  the  default 
size  for  enumeration  types  with  128  or  less  elements  is  8  bits,  the  default  size 
for  enumeration  types  with  129  to  32768  elements  is  16  bits.  Because  this 
implementation  does  not  support  enumeration  types  with  more  than  32768 
elements,  a  size  specification  or  enumeration  representation  clause  must  be  used 
for  enumeration  types  that  use  a  32-bit  representation. 

When  a  size  specification  is  applied  to  an  enumeration  type,  this  enumeration 
type  and  all  of  its  subtypes  have  the  size  specified  by  the  length  clause.  The 
size  specification  must  specify  a  value  greater  than  or  equal  to  the  minimum 
size  of  the  type.  Note  that  if  the  size  specification  specifies  the  minimum  size 
and  none  of  the  internal  codes  are  negative  integers,  the  internal  representation 
will  be  that  of  an  unsigned  type.  Thus,  when  using  a  size  specification  of  eight 
bits,  you  can  have  up  to  256  elements  in  the  enumeration  type. 

If  the  enumeration  type  is  used  as  a  component  type  in  an  array  or 
record  definition  that  is  further  constrained  by  a  pragma  PACK  or  a  record 
representation  clause,  the  size  of  this  component  will  be  determined  by  the 
pragma  PACK  or  the  record  representation  clause.  This  allows  the  array  or 
record  type  to  temporarily  override  any  size  specification  that  may  have 
applied  to  the  enumeration  type. 

The  Ada  compiler  provides  a  complete  implementation  of  size  specifications. 
•Nevertheless,  because  enumeration  values  are  coded  using  integers,  the  specified 
length  cannot  be  greater  than  32  bits. 

F  4.1.4  Alignment  of  an  Enumeration  Type 

An  enumeration  type  is  byte-aligned  if  the  size  of  the  type  is  less  than  or  equal 
to  eight  bits.  .An  enumeration  type  is  aligned  on  a  2- byte  boundary  (16  bit 
or  half-word  aligned)  if  the  size  of  the  type  is  in  the  range  of  9.. 16  bits.  An 
enumeration  typo  is  aligned  on  a  4-byte  boundary  (32  bit  or  word  aligned)  if 
the  size  of  the  type  is  in  the  range  of  17. ..32  bits. 
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F  4.2  Integer  Types 


F  42.1  Predefined  Integer  Types 

The  HP  9000  Series  600,  700,  and  800  Computer  Systems  provides  these  three 


predefined  integer  types: 

type  SHORT.SHORT. INTEGER 
is  range  -(2**7) 

..  (2**7)-l; 

—  8-bit 

signed 

type  SHORT.INTEGER 

is  range  -(2**15) 

..  (2**15)-1; 

—  16-bit 

signed 

type  INTEGER 

is  range  -(2**31) 

..  (2**31)-1; 

—  32-bit 

signed 

An  integer  type  declared  by  a  declaration  of  the  form 


type  T  is  range  L  ..  U; 

is  implicitly  derived  from  a  predefined  integer  type.  The  compiler 
automatically  selects  the  .mal’.est  predefined  integer  type  whose  range  contains 
the  values  L  to  U,  inclusi\  ’ 


F  4.2.2  Internal  Codes  of  Integer  Values 

The  internal  codes  for  integer  values  are  represented  using  the  two’s 
complement  binary  method.  The  compiler  does  not  represent  integer  values 
using  any  kind  of  a  bias  representation.  Thus,  one  internal  code  will  always 
represent  the  same  literaJ  value  for  any  Ada  integer  type. 
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F  4.2.3  Minimum  Size  of  an  Integer  Type  or  Subtype 

The  minimum  size  of  an  integer  subtype  is  the  minimum  number  of  bits 
necessary  for  representing  the  internal  codes  of  the  subtype. 

A  static  subtype  of  a  null  range  has  a  minimum  size  of  one.  Otherwise,  define  m 
and  M  to  be  the  smallest  and  largest  values  for  the  internal  codes  values  of  the 
subtype. 

The  minimum  size  L  is  determined  as  follows; 


Value  of  m 

Calculation  of  L  - 
smallest  positive  integer  suclt  that: 

Representation 

m  >=  0 

M  <2^  -1 

Unsigned 

ni  <  0 

— <  m  and  M  <  —  1 

Signed  two’s  complement 
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Example 


type  MY.INT  is  range  0  ..  31; 

—  The  minimum  size  of  MY.INT  is  5  bits  using 

—  an  imsigned  representation 

subtype  SOME.INT  is  MY.INT  range  5  ..  7; 

--  The  minimum  size  of  SOME.INT  is  3  bits . 

—  The  internal  representation  of  7  requires  three 

—  binary  bits  using  unsigned  representation. 

subtype  DYNAMIC.INT  is  MY.INT  range  L  . .  U; 

—  Assuming  that  L  and  U  are  dynamic, 

— (i.e.  not  known  at  compile  time) 

"  The  minimum  size  of  DYNAMIC.INT  is  the  same  as  its  base  type, 

—  MY.INT,  which  is  5  bits. 

type  ALT.INT  is  range  -1  ..  16; 

"  The  minimum  size  of  MY.INT  is  6  bits, 

—  because  using  a  5-bit  signed  integer  we 

—  can  only  represent  numbers  in  the  range  - 16  . .  15 

—  and  using  a  6-bit  signed  integer  we 

—  can  represent  numbers  in  the  range  -32  . .  31 

—  Since  we  must  represent  16  as  well  as  -1  the 

—  compiler  must  choose  a  6-bit  signed  representation 
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F  4^.4  Size  of  an  Integer  Type 

The  sizes  of  the  predefined  integer  types  SHORT_SHORT_INTEGER, 
SHORT.INTEGER  and  INTEGER  are  8,  16,  and  32  bits,  respectively. 

When  no  size  specification  is  applied  to  an  integer  type,  the  default  size  is  that 
of  the  predefined  integer  type  from  which  it  derives,  directly  or  indirectly. 

Example 

type  S  is  range  80  ..  100; 

—  Type  S  is  derived  from  SHORT.SHDRT. INTEGER 

—  its  default  size  is  8  bits. 

type  N  is  range  0  . .  255 ; 

—  Type  M  is  derived  from  SHORT.INTEGER 

—  its  default  size  is  16  bits. 

type  Z  is  new  M  range  80  . .  100; 

—  Type  Z  is  indirectly  derived  from  SHORT.INTEGER 

its  default  size  is  16  bits. 

type  L  is  range  0  ..  99999; 

—  Type  L  is  derived  from  INTEGER 

—  its  default  size  is  32  bits. 

type  UNSIGNED.BYTE  is  range  0  ..  (2**8)-l; 
for  UNSIGNED.BYTE’SIZE  use  8; 

—  Type  UNSIGNED.BYTE  is  derived  from  SHORT.INTEGER 
--  its  actual  size  is  8  bits. 

type  UNSIGNED .HALFWORD  is  range  0  ..  (2**16)-1; 
for  UNSIGNED.HALFWORD’SIZE  use  16; 

—  Type  UNSIGNED.HALFWORD  is  derived  from  INTEGER 

—  its  actual  size  is  16  bits. 
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When  a  size  specification  is  applied  to  an  integer  type,  this  integer  type 
and  all  of  its  subtypes  have  the  size  specified  by  the  length  clause.  The  size 
specification  must  specify  a  value  greater  than  or  equal  to  the  minimum  size 
of  the  type.  If  the  size  specification  specifies  the  minimum  size  and  the  lower 
bound  of  the  range  is  not  negative,  the  internal  representation  will  be  unsigned. 
Thus,  when  using  a  size  specification  of  eight  bits,  you  can  represent  an  integer 
range  from  0  to  255. 

Using  a  size  specification  on  an  integer  type  allows  you  to  define  unsigned 
machine  integer  types.  The  compiler  fully  supports  unsigned  machine  integer 
types  that  are  either  8  or  16  bits.  The  8-bit  unsigned  machine  integer  type 
is  derived  from  the  16-bit  predefined  type  SHORT. INTEGER.  Using  the  8-bit 
unsigned  integer  type  in  an  expression  results  in  it  being  converted  to  the 
predefined  16-bit  signed  type  for  use  in  the  expression.  This  same  method  also 
applies  to  the  16-bit  unsigned  machine  integer  type,  such  that  using  the  type  in 
an  expression  results  in  a  conversion  to  the  predefined  32-bit  signed  type. 

However,  Ada  does  not  allow  the  definition  of  an  unsigned  integer  type  that 
has  a  greater  range  than  the  largest  predefined  integer  type.  INTEGER  is  the 
largest  predefined  integer  type  and  is  represented  as  a  32-bit  signed  machine 
integer.  Because  the  Ada  language  requires  predefined  integer  types  to  be 
symmetric  about  zero  {Ada  RM,  section  3.5.4),  it  is  not  possible  to  define  a 
32-bit  unsigned  machine  integer  type  because  the  largest  predefined  integer 
type,  INTEGER,  is  also  a  32-bit  type. 

If  the  integer  type  is  used  as  a  component  type  in  an  array  or  record  definition 
that  is  further  constrained  by  a  pragma  PACK  or  record  representation  clause, 
the  size  of  this  component  will  be  determined  by  the  pragma  PACK  or  record 
representation  clause.  This  allows  the  array  or  record  type  to  temporarily 
override  any  size  specification  that  may  have  applied  to  the  integer  type. 

The  Ada  compiler  provides  a  complete  implementation  of  size  specifications. 
Nevertheless,  because  integers  are  coded  using  machine  integers,  the  specified 
length  cannot  be  greater  than  32  bits. 
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F  4.2.5  Alignment  of  an  Integer  Type 

An  integer  type  is  byte-aligned  if  the  size  of  the  type  is  less  than  or  equal  to 
eight  bits.  An  integer  type  is  aligned  on  a  2-byte  boundary  (16  bit  or  half-word 
aligned)  if  the  size  of  the  type  is  in  the  range  of  9.. 16  bits.  An  integer  type  is 
aligned  on  a  4-byte  boundary  (32  bit  or  word  aligned)  if  the  size  of  the  type  is 
in  the  range  of  17. .32  bits. 


F  4.2.6  Performance  of  an  Integer  Type 

The  type  INTEGER  is  the  most  efficient  of  the  integer  types  in  Ada/800  because 
the  hardware  can  access  these  integers  and  perform  overflow  checks  on  them 
with  no  additional  cost.  For  the  smaller  integer  types  (SHORT.INTEGER  and 
SHORT. SHORT. INTEGER),  the  compiler  must  emit  additional  instructions  for 
access  and  overflow  checking  that  increase  both  the  execution  time  and  the  size 
of  the  generated  code. 
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F  4.3  Floating  Point  Types 


F  4.3.1  Predefined  Floating  Point  Types 

The  HP  9000  Series  600/700/800  Computer  Systems  provides  two  predefined 
floating  point  types. 

type  FLOAT  is  digits  6  range 

-(2.0  -  2.0**(-23))*(2.0**127)  .. 

♦(2.0  -  2.0**(-23))*(2.0**127); 

—  This  expresses  the  decimal  range  -3.40282E+38  ..  3.40282E+38 

type  LONG.FLOAT  is  digits  15  range 

-(2.0  -  2. 0**(-52))*(2. 0**1023)  .. 

+(2.0  -  2. 0**(-52))*(2. 0**1023); 

—  This  expresses  the  decimal  range; 

—  -1. 797693 13486231SE+308  ..  ♦1.797693134862315E+308 

A  floating  point  type  declared  by  a  declaration  of  the  form 

type  T  is  digits  D  [range  L  . .  U] ; 

is  implicitly  derived  from  a  predefined  floating  point  type.  The  compiler 
automatically  selects  the  smaller  of  the  two  predefined  floating  point  types, 
FLOAT  or  LONG.FLOAT,  whose  number  of  digits  is  greater  than  or  equal  to  D  and 
that  contains  the  values  L  to  U  inclusive. 


F  4.3.2  Internal  Codes  of  Floating  Point  Values 

The  internal  codes  for  floating  point  values  are  represented  using  the  IEEE 
standard  formats  for  single  precision  and  double  precision  floats. 

The  values  of  the  predefined  type  FLOAT  are  represented  using  the  single 
precision  float  format.  The  values  of  the  predefined  type  LONG.FLOAT  are 
represented  using  the  double  precision  float  format.  The  values  of  any  other 
floating  point  type  are  represented  in  the  same  way  as  the  values  of  the 
predefined  type  from  which  it  derives,  directly  or  indirectly. 
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The  interna]  representation  of  the  IEEE  floating  point  types  can  be  described 
by  the  following  Ada  specification 

type  BIT  is  range  0..1; 
for  BIT’SIZE  use  1; 


IEEE  representation  for  32-bit  FLOAT  type 


FL0AT32_BIAS  :  constant  :»  2<“»7-l; 

type  FL0AT32_EXP0NENT  is  range  0  ..  2**8- 1; 
for  FL0AT32_EXP0NENT'SI2E  use  8; 

type  FL0AT32.MANTISSA  is  array(0..22)  of  BIT; 
for  FL0AT32.MANTISSA*SIZE  use  23; 

type  FL0AT32_REC  is 
record 

SIGN.BIT  :  BIT; 

EXPONENT  :  FL0AT32.EXP0NENT; 

MANTISSA  :  FL0AT32.MANTISSA ; 

end  record ; 
for  FL0AT32.REC  use 
record 

.  SIGN.BIT  at  0  range  0  ..  0; 

EXPONENT  at  0  range  1  . .  8 ; 

MANTISSA  at  0  range  9  . .  31 ; 

end  record; 

for  FL0AT32_REC’SIZE  use  32; 


IEEE  representation  for  64-bit  FLOAT  type 


FL0AT64_BIAS  :  constant  2**10-1; 

type  FL0AT64. EXPONENT  is  range  0  ..  2**11-1; 
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for  FL0AT64_EXP0NENT’SIZE  use  11; 

type  FL0AT64,HANTISSA  is  array(0..51)  of  BIT; 
for  FL0AT64.HANTISSA’SIZE  use  52; 

type  FL0AT64_REC  is 
record 

SIGN.BIT  :  BIT; 

EXPONENT  :  FL0AT64_EXP0NENT ; 

MANTISSA  :  FL0AT64_MANTISSA ; 

end  record: 
for  FL0AT64_REC  use 
record 

SIGN.BIT  at  0  range  0  ..  0; 

EXPONENT  at  0  range  1  ..  11; 

MANTISSA  at  0  range  12  ..  63; 

end  record; 

for  FL0AT64,REC’SIZE  use  64; 


4-14  F  4.  Type  Representation 


F  4.3.3  Minimum  Size  of  a  Floating  Point  Type  or  Subtype 

The  minimum  size  of  a  floating  point  subtype  is  32  bits  if  its  base  type  is 
FLOAT  or  a  type  derived  from  FLOAT;  it  is  64  bits  if  its  baise  type  is  LONG.FLOAT 
or  a  type  derived  from  LONG.FLOAT. 


F  4.3.4  Size  of  a  Floating  Point  Type 

The  only  size  that  can  be  specified  for  a  floating  point  type  in  a  size 
specification  is  its  default  size  (32  or  64  bits). 


F  4.3.5  Alignment  of  a  Floating  Point  Type 

A  floating  point  type  FLOAT  is  aligned  on  a  4-byte  boundary  (32  bit  or  word 
aligned).  The  floating  point  type  LOMG.FLOAT  is  aligned  on  an  8-byte  boundary 
(64  bit  or  double-word  aligned). 
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F  4.4  Fixed  Point  Types 


F  4.4.1  Predefined  Fixed  Point  Types 

To  implement  fixed  point  types,  the  HP  9000  Series  600,  700,  and  800 
Computer  System  provides  a  set  of  three  anonymous  predefined  fixed  point 
types  of  this  form; 

type  SHORT.FIXED  is  delta  D  range 

-(2**7)*SMALL  ..  +((2**7)-l)*SMALL; 
for  SHORT.FIXED’ SMALL  use  SMALL; 
for  SHORT.FIXED ’SIZE  use  8; 

type  FIXED  is  delta  D  range 

-(2**15)*SMALL  ..  +((2**15)-1)*SMALL; 
for  FIXED ’SMALL  use  SMALL; 
for  FIXED ’SIZE  use  16; 

type  LONG.FIXED  is  delta  D  range 

-(2**31)*SMALL  ..  ♦((2**31)-1)*SMALL: 
for  LONG.FIXED ’SHALL  use  SMALL; 
for  LONG.FIXED ’SIZE  use  32; 

—  In  the  above  type  definitions  SMALL  is  the  largest 

—  power  of  tug  that  is  less  than  or  equal  to  D. 


A  fixed  point  type  declared  by  a  declaration  of  the  form 
type  T  is  delta  D  range  L  ..  U; 
is  implicitly  derived  from  one  of  the  predefined  fixed  point  types. 
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The  compiler  automatically  selects  the  smallest  predefined  fixed  point  type 
using  the  following  method: 

■  Choose  the  largest  power  of  two  that  is  not  greater  than  the  value  specified 
for  the  delta  to  use  as  SMALL. 

■  Determine  the  ranges  for  the  three  predefined  fixed  point  types  using  the 
value  obtained  for  SMALL. 

■  Select  the  smallest  predefined  fixed  point  type  whose  range  contains  the 
values  L+SMALL  to  U-SMALL,  inclusive. 

Using  the  above  method,  it  is  possible  that  the  values  L  and  U  lie  outside  the 
range  of  the  compiler-selected  fixed  point  type.  For  this  reason,  the  values  used 
in  a  fixed  point  range  constraint  should  be  expressed  as  follows,  to  guarantee 
that  the  values  of  L  and  U  are  representable  in  the  resulting  fixed  point  type: 

type  ANY.FIXED  is  delta  D  range  L-D  ..  U+D; 

—  The  values  of  L  and  U  are  guaranteed  to  be 
--  representable  in  the  type  ANY.FIXED. 


F  4.4.2  Internal  Codes  of  Fixed  Point  Values 

The  internal  codes  for  fixed  point  values  are  represented  using  the  two’s 
complement  binary  method  as  integer  multiples  of  ’SMALL.  The  value  of  a  fixed 
l)oint  object  is  ’SMALL  multiplied  by  the  stored  internal  code. 


F  4.4.3  Small  of  a  Fixed  Point  Type 

The  Ada  compiler  requires  that  the  value  assigned  to  ’SMALL  is  always  a  power 
of  two.  Ada  does  not  support  a  length  clause  that  specifies  a  ’SMALL  for  a  fixed 
point  type  that  is  not  a  power  of  two. 

If  a  fixed  point  type  does  not  have  a  length  clause  that  specifies  the  value  to 
use  for  ’SMALL,  the  value  of  ’SMALL  is  determined  by  the  compiler  according  to 
the  rules  in  the  Ada  RM.  section  3.5.9. 
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F  4.4.4  Minimum  Size  of  a  Fixed  Point  Type  or  Subtype 

The  minimum  size  of  a  fixed  point  subtype  is  the  minimum  number  of  binary 
digits  necessary  to  represent  the  values  in  the  range  of  the  subtype  using  the 
’SMALL  of  the  base  type. 

A  static  subtype  of  a  null  range  has  a  minimum  size  of  one.  Otherwise,  define 
s  and  S  to  be  the  bounds  of  the  subtype,  define  m  and  M  to  be  the  smallest 
and  greatest  model  numbers  of  the  base  type,  and  let  i  and  I  be  the  integer 
representations  for  the  model  numbers  m  and  M.  The  following  axioms  hold: 

s  <=  m  <  M  <=  S 
m  -  T’ BASE ’SMALL  <=  s 
M  +  T’BASE’SMALL  >*  S 
M  *  T’ BASE ’LARGE 
i  »  m  /  T’BASE’SMALL 
I  =  M  /  T’BASE’SMALL 

The  minimum  size  L  is  determined  as  follows: 


Value  of  i 

Calculation  of  L  • 
smallest  positive  integer  sucli  that: 

Representation 

»  >  0 

/  <  2^  -  1 

Unsigned 

«  <  0 

-2^-*  <  i  and  I  <  2^“*  -  1 

Signed  two’s  complement 
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Example 

type  UF  is  delta  0.1  range  0.0  ..  100.0; 

—  The  value  used  for  'SMALL  is  0.0625 

—  The  minimum  size  of  UF  is  11  bits, 

—  seven  bits  before  the  decimal  point 

—  four  bits  after  the  decimal  point 

—  and  no  bits  for  the  sign. 

type  SF  is  delta  16.0  range  -400.0  ..  400.0; 

—  The  minimum  size  of  SF  is  6  bits, 

—  nine  bits  to  represent  the  range  0  to  511 

—  less  four  bits  by  the  implied  decimal  point  of  16.0 

—  and  one  bit  for  the  sign. 

subtype  UFS  is  UF  delta  4.0  range  0.0  ..  31.0; 

—  The  minimum  size  of  UFS  is  9  bits, 

—  five  bits  to  represent  the  range  0  to  31 

—  four  bits  for  the  small  of  0.0625  from  the  base  type 

—  and  no  bits  for  the  sign. 

subtype  SFD  is  SF  range  X  . .  Y; 

—  Assiiming  that  X  and  Y  are  not  static,  the  minimum  size 

—  of  SFD  is  6  bits,  (the  same  as  its  base  type) 
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F  4.4.5  Size  of  a  Fixed  Point  Type 

The  sizes  of  the  anonymous  predefined  fixed  point  types  SHORT_FIXED,  FIXED, 
and  LONG.FIXED  are  8,  16,  and  32  bits,  respectively. 

When  no  size  specification  is  applied  to  a  fixed  point  type,  the  default  size 
is  that  of  the  predefined  fixed  point  type  from  which  it  derives,  directly  or 
indirectly. 

Example 

type  Q  is  delta  0.01  range  0.00  ..  1.00; 

—  Type  Q  is  derived  from  an  8-bit  predefined 

—  fixed  point  type,  its  default  size  is  8  bits. 

type  R  is  delta  0.01  range  0.00  ..  2.00; 

—  T3rpe  R  is  derived  from  a  16-bit  predefined 

—  fixed  point  type,  its  default  size  is  16  bits. 

type  S  is  new  R  range  0.00  ..  1.00; 

—  Type  S  is  indirectly  derived  from  a  16-bit  predefined 

—  fixed  point  type,  its  default  size  is  16  bits. 

type  SF  is  delta  16.0  range  -400.0  ..  400.0; 
for  SF'SIZE  use  6; 

—  Type  SF  is  derived  from  an  8-bit  predefined 

—  fixed  point  .type,  its  actual  size  is  6  bits. 

type  UF-  is  delta  0.1  range  0.0  ..  100.0; 
for  UF’SIZE  use  11; 

—  Type  UF  is  derived  from  a  16-bit  predefined 

—  fixed  point  type,  its  actual  size  is  11  bits. 

—  The  value  used  for  ’SMALL  is  0.0625 
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When  a  size  specification  is  applied  to  a  fixed  point  type,  this  fixed  point  type 
and  all  of  its  subtypes  have  the  size  specified  by  the  length  clause.  The  size 
specification  must  specify  a  value  greater  than  or  equal  to  the  minimum  size 
of  the  type.  If  the  size  specification  specifies  the  minimum  size  and  the  lower 
bound  of  the  range  is  not  negative,  the  internal  representation  will  be  that  of 
an  unsigned  type. 

If  the  fixed  point  type  is  used  as  a  component  type  in  an  array  or 
record  definition  that  is  further  constrained  by  a  pragma  PACK  or  record 
representation  clause,  the  size  of  this  component  will  be  determined  by  the 
pragma  PACK  or  record  representation  clause.  This  zJlows  the  array  or  record 
type  to  temporarily  override  any  size  specification  that  may  have  applied  to  the 
fixed  point  type. 

The  Ada  compiler  provides  a  complete  implementation  of  size  specifications. 
Nevertheless,  because  fixed  point  objects  are  coded  using  machine  integers,  the 
specified  length  cannot  be  greater  than  32  bits. 


F  4.4.6  Alignment  of  a  Fixed  Point  Type 

A  fixed  point  type  is  byte-aligned  if  the  size  of  the  type  is  less  than  or  equal 
to  eight  bits.  A  fixed  point  type  is  aligned  on  a  2-byte  boundary  (16  bit  or 
half-word  aligned)  if  the  size  of  the  type  is  in  the  range  of  9. .16  bits.  A  fixed 
point  type  is  aligned  on  a  4-byte  boundary  (32  bit  or  word  aligned)  if  the  size 
of  the  type  is  in  the  range  of  17..32  bits. 
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F  4.5  Access  Types 


F  4.5.1  Internal  Codes  of  Access  Values 

In  the  program  generated  by  the  compiler,  access  values  are  represented 
using  32-bit  machine  addresses.  The  predefined  generic  function 
UNCHECKEO.CONVERSION  can  be  used  to  convert  the  internal  representation 
of  an  access  value  into  any  other  32-bit  type.  You  can  also  use 
UNCHECKED.CONVERSION  to  assign  any  32-bit  value  into  an  access  value.  When 
interfacing  with  externally  supplied  data  structures,  it  may  be  necessary  to  use 
the  generic  function  UNCHECKED.CONVERSION  to  convert  a  value  of  the  type 
SYSTEM .  ADDRESS  into  the  internal  representation  of  an  access  viJue.  Programs 
that  use  UNCHECKED.CONVERSION  in  this  manner  cannot  be  considered  portable 
across  different  implementations  of  Ada. 


F  4.52  Collection  Size  for  Access  Types 

A  length  clause  that  specifies  the  collection  size  is  allowed  for  an  access  type. 
This  collection  size  applies  to  all  objects  of  this  type  and  any  type  derived 
from  this  type,  as  well  as  any  and  all  subtypes  of  these  types.  Thus,  a  length 
clause  that  specifies  the  collection  size  is  only  allowed  for  the  original  base  type 
definition  and  not  for  any  subtype  or  derived  type  of  the  base  type. 

When  no  specification  of  collection  size  applies  to  an  access  type,  the  attribute 
STORAGE.SIZE  return^  zero.  In  this  case,  the  compiler  will  dynamically  manage 
the  storage  for  the  access  type  and  it  is  not  possible  to  determine  directly  the 
amount  of  storage  avjulable  in  the  collection  for  the  access  type. 
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The  recommended  format  of  a  collection  size  length  clause  is: 

U_NUM:  constant  :=  50;  —  The  maximum  number 
—  of  elements  needed 

U.SIZE:  constant  :=  <U  siz€>;  —  Substitute  the  value 

—  of  U’SIZE  here 


—  The  constant  U.SIZE  should  also  be: 

—  1.  a  multiple  of  two 

—  2.  greater  than  or  equal  to  four 

—  Additionally,  the  type  U  must  have  a  static  size 

type  P  is  access  U;  —  Type  U  is  any 
--  non-dynamic  user  defined  t3rp6- 

for  P’STORAGE.SIZE  use  (U.SIZE>»U_NUM)+4 ; 

In  the  above  example  we  have  specified  a  collection  size  that  is  large  enough  to 
contain  50  objects  of  the  type  U.  There  is  a  constant  overhead  of  four  bytes  for 
each  storage  collection.  Because  the  collection  manager  rounds  the  element  size 
to  be  a  multiple  of  two  that  is  four  or  greater,  you  must  ensure  that  U.SIZE 
is  the  smallest  multiple  of  two  that  is  greater  than  or  equal  to  U’SIZE  and  is 
greater  than  or  equal  to  four. 

You  can  also  provide  a  length  clause  that  specifies  the  collection  size  for  a  type 
that  has  a  dynamic  size.  It  is  only  possible  to  specify  an  upper  limit  on  the 
amount  df  memory  that  can  be  used  by  all  instances  of  objects  that  are  of  this 
dynamic  type.  Because  the  size  is  dynamic,  you  cannot  specify  the  number  of 
elements  in  the  collection. 
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F  4.5.3  Minimum  Size  of  an  Access  Type  or  Subtype 

The  tnininiuin  size  of  an  access  type  is  always  32  bits. 


F  4.5.4  Size  of  an  Access  Type 

The  size  of  an  access  type  is  32  bits,  the  same  as  its  minimum  size. 

The  only  size  that  can  be  specified  for  an  access  type  in  a  size  specification 
clause  is  its  usual  size  (32  bits). 


F  4.5.5  Alignment  of  an  Access  Type 

An  access  type  is  aligned  on  a  4-bvie  boundary  (32  bit  or  word-aligned). 
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F  4.6  Task  Types 


F  4.6.1  Internal  Codes  of  Task  Values 

In  the  program  generated  by  the  compiler,  task  type  objects  are  represented 
using  32-bit  machine  addresses. 


F  4.6.2  Storage  for  a  Task  Activation 

The  value  returned  by  the  attribute  *STORAGE_SIZE  has  three  cases. 

■  For  a  task  type  without  a  length  clause  and  using  the  default  storage  size  at 
bind  time,  the  attribute  ’STORAGE.SIZE  returns  the  default  task  storage  size. 

■  For  a  task  type  without  a  length  clause  and  using  the  bind-time  option  -W 
b,-t,nnn  to  set  the  task  storage  size,  the  attribute  *STORAGE_SIZE  returns 
finn*1024. 

B  For  a  task  type  with  a  length  clause,  the  attribute  ’STORAGE.SIZE  returns 
the  value  used  in  the  length  clause. 

When  a  length  clause  is  used  on  a  task  type  it  specifies  the  number  of  storage 
units  reserved  for  an  activation  of  a  tiisk  of  this  type  (Ada  RM  13.2  (10)). 

This  space  includes  both  the  task  stack  space  and  a  private  data  section  of 
appro.\iniately  5400  bytes.  The  private  data  section  contains  the  Task  Control 
Block  which  has  information  used  by  the  Ada  runtime  to  manage  the  task. 

.The  size  specified  in  the  length  clause  must  be  greater  than  this  minimum 
size,  otherwise  a  T.ASKING_ERROR  exception  will  be  generated  during  the 
elaboration  of  the  activation  of  a  task  object  of  this  type.  The  stack  space 
requirements  for  the  task  object  must  also  be  considered.  If  the  stack  space  is 
insufficient  during  the  e.xecution  of  the  task,  the  exception  STOR.AGE_ERROR 
will  be  raised  and  the  task  object  will  be  terminated. 
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An  example  that  sets  the  storage  usage  for  a  task  type  that  needs  4K  bytes  of 
stack  space: 

task  type  MY.TASK.TYPE  is 
entry  START; 
entry  STOP; 
end  HY.TASK.TYPE; 

for  MY.TASK.TYPE ’ST0RAGE.SI2E  use  5400  +  (4  *  1024); 

—  Allocates  a  4K  stack. 


F  4.6.3  Minimum  Size  of  a  Task  Stack 

The  task  object  will  use  800  bytes  of  stack  space  in  the  first  stack  frame.  Some 
additional  stack  space  is  required  to  make  calls  into  the  Ada  runtime.  The 
smallest  value  that  can  be  safely  used  for  a  task  with  minimal  stack  needs  is 
approximctely  2000  bytes.  If  the  task  object  has  local  variables  or  if  it  makes 
calls  to  oth».r  subprograms,  the  stack  storage  requirements  will  be  larger.  The 
actual  amount  of  stack  space  used  by  a  task  will  need  to  be  determined  by  trial 
and  error.  If  a  tasking  program  raises  ST0RAGE.ERR0R  or  behaves  abnormally, 
you  should  increase  the  stack  space  for  the  tsisks. 


F  4.6.4  Limitation  on  Length  Clause  for  Derived  Task  Types 

If  a  task  type  has  a  storage  size  length  clause,  the  storage  size  applies  to  all 
task  objects  of  this  type  and  any  task  type  derived  from  this  type.  Thus,  a 
length  clause  that  specifies  the  storage  size  is  only  allowed  for  the  original  task 
type  definition  and  not  for  any  derived  task  type. 
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F  4.6.5  Minimum  Size  of  a  Task  Type  or  Subtype 

The  minimum  size  of  a  task  type  is  always  32  bits. 


F  4.6.6  Size  of  a  Task  Type 

The  size  of  a  task  type  is  32  bits,  the  same  as  its  minimum  size. 

The  only  size  that  can  be  specified  for  a  task  type  in  a  size  specification  clause 
is  its  usual  size  (32  bits). 


F  4.6.7  Alignment  of  a  Task  Type 

A  task  type  is  aligned  on  a  4- byte  boundary  (32  bit  or  word  aligned). 
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F  4.7  Array  Types 


F  4.7.1  Layout  of  an  Array 

Each  array  is  allocated  in  a  contiguous  area  of  storage  units.  All  the 
components  have  the  same  size.  A  gap  may  exist  between  two  consecutive 
components  (and  after  the  last  component).  All  the  gaps  are  the  same  size,  as 
shown  in  Figure  4-1. 


CempoTMmt  Gap  Componan  Gap  Componam  Gap 


LC200073.0U 

Figure  4-1.  Layout  of  an  Array 


F  4.7.2  Array  Component  Size  and  Pragma  PACK 

If  the  array  is  not  packed,  the  size  of  each  component  is  the  size  of  the 
component  type.  This  size  is  the  default  size  of  the  component  type  unless  a 
size  specification  applies  to  the  component  type. 

If  the  array  is  packed  and  the  array  component  type  is  neither  a  record  nor 
array  type,  the  size  of  the  component  is  the  minimum  size  of  the  component 
type.  The  minimum  size  of  the  component  type  is  used  even  if  a  size 
specification  applies  to  the  component  type. 
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Packing  the  array  has  no  effect  on  the  size  of  the  components  when  the 
component  type  is  a  record  or  array  type. 


Example 

type  A  is  array(1..8)  of  BOOLEAN; 

—  The  component  size  of  A  is  the  default  size 

—  of  the  type  BOOLEAN:  8  bits. 

type  B  is  array(1..8)  of  BOOLEAN; 
pragma  PACK(B); 

—  The  component  size  of  B  is  the  minimum  size 

—  of  the  type  BOOLEAN:  1  bit. 

type  DECIMAL. DIGIT  is  range  0..9; 

—  The  default  size  for  DECIMAL.DIGIT  is  8  bits 

—  The  minimum  size  for  DECIMAL.DIGIT  is  4  bits 

type  BCD.NOT.PACKED  is  array(1..8)  of  DECIMAL.DIGIT; 

--  The  component  size  of  BCD.NOT.PACKED  is  the  default 

—  size  of  the  type  DECIMAL.DIGIT:  8  bits. 

type  BCD.PACKED  is  array(1..8)  of  DECIMAL.DIGIT; 
pragma  PACK (BCD.PACKED) ; 

—  The  component  size  of  BCD.PACKED  is  the  minimum 

—  size  of  the  type  DECIMAL.DIGIT:  4  bits. 


F  4.7.3  Array  Gap  Size  and  Pragma  PACK 

If  the  array  type  is  not  packed  and  the  component  type  is  a  record  type 
without  a  size  specification  clause,  the  compiler  may  choose  a  representation 
for  the  array  with  a  gap  after  each  component.  Inserting  gaps  optimizes  access 
to  the  array  components.  The  size  of  the  gap  is  chosen  so  that  each  array 
component  begins  on  an  alignment  boundary. 

If  the  array  type  is  packed,  the  compiler  will  generally  not  insert  a  gap  between 
the  array  components.  In  such  cases,  access  to  array  components  can  be  slower 
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because  the  array  components  will  not  always  be  aligned  correctly.  However, 
in  the  specific  case  where  the  component  type  is  a  record  and  the  record  has 
a  record  representation  clause  specifying  an  alignment,  the  alignment  will  be 
honored  and  gaps  may  be  inserted  in  the  packed  array  type. 


Example 

t]rpe  R  is 
record 

K  :  INTEGER;  --  T3rpe  Integer  is  word  aligned. 

B  :  BOOLEAN;  —  Type  Boolean  is  byte  aligned, 

end  record; 

—  Record  type  R  is  word  aligned.  Its  size  is  40  bits, 
type  A  is  array (1.. 10)  of  R; 

—  A  gap  of  three  bytes  is  inserted  after  each  array 

—  component  in  order  to  respect  the  alignment  of  type  R. 

—  The  size  of  array  type  A  is  640  bits. 

type  PA  is  array(l..I0)  of  R; 
pragma  PACK (PA); 

—  There  are  no  gaps  in  an  array  of  type  PA  because 

—  of  the  pragma  PACK  statement  on  type  PA. 

—  The  size  of  array  type  PA  is  400  bits. 

type  NR  is  new  R; 
for  NR’ SIZE  use  40; 

type  B  is  array(1..10)  of  NR; 

—  There  are  no  gaps  in  an  array  of  type  B  because 

—  of  the  size  specification  clause  on  type  NR. 

—  The  size  of  array  type  B  is  400  bits. 
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F  4.7.4  Size  of  an  Array  Type  or  Subtype 

The  size  of  an  array  subtype  is  obtained  by  multiplying  the  number  of  its 
components  by  the  sum  of  the  size  of  the  component  and  the  size  of  the  gap. 

The  size  of  an  array  type  or  subtype  cannot  be  computed  at  compile  time  if 
any  of  the  following  are  true: 

■  If  the  array  has  non-static  constraints  or  if  it  is  an  unconstrained  type  with 
non-static  index  subtypes  (because  the  number  of  components  can  then  only 
be  determined  at  run  time) 

■  If  the  components  are  records  or  arrays  and  their  constraints  or  the 
constraints  of  their  subcomponents  are  not  static  (because  the  size  of  the 
components  and  the  size  of  the  gaps  can  then  only  be  determined  at  run 
time).  Pragma  PACK  is  not  allowed  in  this  case. 

As  indicated  above,  the  effect  of  a  pragma  PACK  on  an  array  type  is  to 
suppress  the  gaps  and  to  reduce  the  size  of  the  components,  if  possible.  The 
consequence  of  packing  an  array  type  is  thus  to  reduce  its  size. 

Array  packing  is  fully  implemented  by  the  Ada  compiler  with  this  limitation: 
if  the  components  of  an  array  type  are  records  or  arrays  and  their  constraints 
or  the  constraints  of  their  subcomponents  are  not  static,  the  compiler  ignores 
any  pragma  PACK  statement  applied  to  the  array  type  and  issues  a  warning 
message. 

A  size  specification  applied  to  an  array  type  has  no  effect.  The  only  size  that 
the  compiler  will  accept  in  such  a  length  clause  is  the  usual  size.  Nevertheless, 
such  a  length  clause  can  be  used  to  verify  that  the  layout  of  an  array  is  as 
expected  by  the  application. 
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F  4.7.5  Alignment  of  an  Array  Type 

If  no  pragma  PACK  applies  to  an  array  type  and  no  size  specification  applies  to 
the  component  type,  the  array  type  is  aligned  as  the  component  type  would 
have  been. 

If  a  pragma  PACK  applies  to  an  array  type  or  if  a  size  specification  applies  to 
the  component  type  (so  that  there  are  no  gaps),  the  alignment  of  the  array 
type  is  as  given  in  Table  4-2 


Table  4-2.  Alignment  and  Pragma  PACK 


Component 

(Normal 

Aligimient) 

Component 

(Alignment  Witldii  the  Array) 

Double- Word 

Word 

Half-Word 

Byte 

Bit 

Double- Word 

Double- Word 

Word 

Half-Word 

Byte 

Word 

Word 

Word 

Half-Word 

Byte 

■ 

Half-Word 

Half-Word 

Half-Wwd 

Half-Word 

Byte 

Bit 

Byte 

Byte 

Byte 

Byte 

Byte 

Bit 

Bit 

Bit 

Bit 

Bit 

Bit 

Bit 

4-32  F  4.  Type  Representation 


I 


F  4.8  Record  Types 

Syntax  (record  representation  clause) 

for  record-type-name  use 
record  [  alignment-clause  3 
[.component-clause  3 

end  record ; 

Syntax  (alignment  clause) 
at  mod  static-expression 

Syntax  (component  clause) 

record-component-name  at  static-expression 

range  static-expression  . .  static-expression  ; 


F  4.8.1  Layout  of  a  Record 

A  record  is  allocated  in  a  contiguous  area  of  storage  units.  The  size  of  a  record 
depends  on  the  size  of  its  components  and  the  size  of  any  gaps  between  the 
components.  The  compiler  may  add  additional  components  to  the  record. 

These  components  are  ctilled  implicit  components. 

The  positions  and  sizes  of  the  components  of  a  record  type  object  can  be 
controlled  using  a  record  representation  clause  as  described  in  the  Ada  RM , 
section  13.4.  If  the  record  contains  compiler-generated  implicit  components, 
their  position  also  can  be  controlled  using  the  proper  component  clause.  For 
more  details,  see  section  “F  4.8.6  Implicit  Components”.  In  the  implementation 
for  the  HP  9000  Series  600,  700.  and  800  Computer  Systems,  there  is  no 
restriction  on  the  position  that  can  be  specified  for  a  component  of  a  record. 

If  the  component  is  not  a  record  or  an  array,  its  size  can  be  any  size  from  the 
minimum  size  to  the  default  size  of  its  base  type.  If  the  component  is  a  record 
or  an  array,  its  size  must  be  the  size  of  its  base  type. 
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Example  (Record  with  a  representation  danse): 

type  PSW.BIT  is  new  BOOLEAN; 
for  PSW.BIT ’SIZE  use  1; 

type  CABRY.BORROW  is  array  (1..8)  of  PSW.BIT; 
pragma  PACK  (CARRY.BORROW) ; 

FIRST.BYTE  :  constant  ;=  0; 

CABO.BYTE  :  constant  :=  1; 

THIRD.BYTE  :  constant  :=  2; 

SYSMASK.BYTE:  constant  :=  3; 

type  PSW  is 
record 

T  :  PSW.BIT; 

H  :  PSW.BIT: 

L  :  PSW.BIT; 

N  :  PSW.BIT; 

X  :  PSW.BIT; 

B  :  PSW.BIT; 

C  :  PSW.BIT; 

V  :  PSW.BIT; 

M  :  PSW.BIT; 

CB  ;  CARRY.BORROW; 

R  :  PSW.BIT; 

Q  :  PSW.BIT; 

P  :  PSW.BIT; 

D'  :  PSW.BIT; 

I  ;  PSW.BIT; 
end  record; 

—  This  type  can  be  used  to  map  the  status  register  of 
--  the  HP-PA  processor. 
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for  PSW  use 

record  at  mod  4; 


T 

at 

FIRST.BYTE 

range 

7.  .7 

H 

at 

SECOND.BYTE 

range 

0.  .0 

L 

at 

SECOND.BYTE 

range 

1..1 

N 

at 

SECOND.BYTE 

range 

2.  .2 

X 

at 

SECOND.BYTE 

range 

3.  .3 

B 

at 

SECOND.BYTE 

range 

4.  .4 

C 

at 

SECOND.BYTE 

range 

5.  .5 

V 

at 

SECOND.BYTE 

range 

6.  .6 

M 

at 

SECOND.BYTE 

range 

7.  .7 

CB 

at 

CABO.BYTE 

range 

0.  .7 

R 

at 

SYSMASK.BYTE 

range 

3.  .3 

Q 

at 

SYSMASK.BYTE 

range 

4.  .4 

P 

at 

SYSMASK.BYTE 

range 

5.  .5 

D 

at 

SYSMASK.BYTE 

range 

6.  .6 

1 

at 

SYSMASK.BYTE 

range 

7.  .7 

end  record; 

In  the  above  example,  the  record  representation  clause  explicitly  tells  the 
compiler  both  the  position  and  size  for  each  of  the  record  components.  The 
optional  alignment  clause  specifies  a  4-byte  alignment  for  this  record.  In  this 
example  every  component  has  a  corresponding  component  clause,  although 
it  is  not  required.  If  one  is  not  supplied,  the  choice  of  the  storage  place  for 
that  component  is  left  to  the  compiler.  If  component  clauses  are  given  for  all 
components,  including  any  implicit  components,  the  record  representation 
clause  completely  specifies  the  representation  of  the  record  type  and  will  be 
obeyed  exactly  by  the  compiler. 


F  4.8.2  Bit  Ordering  in  a  Component  Clause 

The  HP  -Ada  compiler  for  the  HP  9000  Series  800  Computer  System  numbers 
the  bits  in  a  component  clause  starting  from  the  most  significant  bit.  Thus,  bit 
zero  represents  the  most  significant  bit  of  an  8-bit  byte  and  bit  seven  represents 
the  least  significant  bit  of  the  byte. 
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F  4.8.3  Value  used  for  SYSTEM.STOR AGE.  UNIT 

The  smallest  directly  addressable  unit  on  the  HP  9000  Series  600/700/800 
Computer  Systems  is  the  8-bit  byte.  This  is  the  value  used  for 
SYSTEM. STORAGE.UNIT  that  is  implicitly  used  in  a  component  clause.  A 
component  clause  specifies  an  offset  and  a  bit  range.  The  offset  in  a  component 
clause  is  measured  in  units  of  SYSTEM. STORAGE.UNIT,  which  for  the  HP  9000 
Series  600/700/800  Computer  Systems  is  an  8-bit  byte. 

The  compiler  determines  the  actual  bit  address  for  a  record  component  by 
combining  the  byte  offset  with  the  bit  range.  There  are  several  different 
ways  to  refer  to  the  same  bit  address.  In  the  following  example,  each  of  the 
component  clauses  refer  to  the  same  bit  address. 

Example 

COMPONENT  at  0  range  16  ..  18; 

COMPONENT  at  1  range  8  ..  10; 

COMPONENT  at  2  range  0  . .  2; 


F  4.8.4  Compiler-Chosen  Record  Layout 

If  no  component  clause  applies  to  a  component  of  a  record,  its  size  is  the  size 
of  the  base  type.  Its  location  in  the  record  layout  is  chosen  by  the  compiler  so 
as  to  optimize  access  to  the  component.  That  is,  each  component  of  a  record 
follows  the  natural  alignment  of  the  component’s  base  type.  Moreover,  the 
compiler  chooses  the  position  of  the  components  to  reduce  the  number  of  gaps 
or  holes  in  the  record  and  additionally  to  reduce  the  size  of  the  record. 

Because  of  these  optimizations,  there  is  no  connection  between  the  order  of 
the  components  in  a  record  type  declaration  and  the  positions  chosen  by  the 
compiler  for  the  components  in  a  record  object. 
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F  4.8.5  Change  in  Representation 

It  is  possible  to  apply  a  record  representation  clause  to  a  derived  record  type. 
This  allows  a  record  type  to  possibly  have  several  alternative  representations. 
Thus,  the  compiler  fully  supports  the  “Change  in  Representation”  as  described 
in  the  Ada  RM,  section  13.6. 


F  4.8.6  Implicit  Components 

In  some  circumstances,  access  to  a  record  object  or  to  a  component  of  a 
record  object  involves  computing  information  that  only  depends  on  the 
discriminant  values  or  on  a  value  that  is  known  only  at  run  time.  To  avoid 
unnecessary  recomputation,  the  compiler  reserves  space  in  the  record  to  store 
this  information.  The  compiler  will  update  this  information  whenever  a 
discriminant  on  which  it  depends  changes.  The  compiler  uses  this  information 
whenever  the  component  that  depends  on  this  information  is  accessed.  This 
information  is  stored  in  special  components  called  implicit  components.  There 
are  three  different  kinds  of  implicit  components: 

■  Components  that  contain  an  offset  value. 

■  Components  that  contain  information  about  the  record  object. 

■  Components  that  are  descriptors. 
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Implicit  components  that  contain  an  offset  value  from  the  beginning  of  the 
record  are  used  to  access  indirect  components.  Implicit  components  of  this 
kind  are  called  offset  components.  The  compiler  introduces  implicit  offset 
components  whenever  a  record  contains  indirect  components.  These  implicit 
components  are  considered  to  be  declared  before  any  variant  part  in  the  record 
type  definition.  Implicit  components  of  this  kind  cannot  be  suppressed  by 
using  the  pragma  IMPROVE. 

Implicit  components  that  contain  information  about  the  record  object  are  used 
when  the  record  object  or  component  of  a  record  object  is  accessed.  Implicit 
components  of  this  kind  are  used  to  make  references  to  the  record  object 
or  to  make  record  components  more  efficient.  These  implicit  components 
are  considered  to  be  declared  before  any  variant  part  in  the  record  type 
definition.  There  are  two  implicit  components  of  this  kind:  RECORD.SIZE  and 
VARIANT.INDEX.  Implicit  components  of  this  kind  can  be  suppressed  by  using 
the  pragma  IMPROVE. 

The  third  kind  of  implicit  components  are  descriptors  that  are  used  when 
accessing  a  record  component.  The  implicit  component  e.\ists  whenever  the 
record  has  an  array  or  record  component  that  depends  on  a  discriminant  of 
the  record.  An  implicit  component  of  this  kind  is  considered  to  be  declared 
immediately  before  the  record  component  it  is  associated  with.  There  are  two 
implicit  components  of  this  kind:  ARRAY.DESCRIPTOR  and  RECORD. DESCRIPTOR. 
Implicit  components  of  this  kind  cannot  be  suppressed  by  using  the  pragma 
IMPROVE. 


Note  The  -S  option  (Assembly  Option)  to  the  ada(l)  command  is 

useful  for  finding  out  what  implicit  components  are  associated 
with  the  record  type.  This  option  will  detail  the  exact 
representation  for  all  record  types  defined  in  a  compilation  unit. 
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F  4.8.7  Indirect  Components 

If  the  offset  of  a  component  cannot  be  computed  at  compile  time,  the  compiler 
will  reserve  space  in  the  record  for  the  computed  offset.  The  compiler  computes 
the  value  to  be  stored  in  this  offset  at  run  time.  A  component  that  depends  on 
a  run  time  computed  offset  is  said  to  be  an  indirect  component,  while  other 
components  are  said  to  be  direct. 

A  pictorial  example  of  a  record  layout  with  an  indirect  component  is  shown  in 
Figure  4-2. 
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Figure  4>2.  Record  layout  with  an  Indirect  Component 

In  the  above  example,  the  component  D  has  an  offset  that  cannot  be  computed 
at  compile  time.  The  compiler  then  will  reserve  space  in  the  record  to  store  the 
computed  offset  and  will  store  this  offset  at  run  time.  The  other  components 
(A,  B,  and  C)  are  all  direct  components  because  their  offsets  can  all  be 
computed  at  compile  time. 
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F  4.8.8  Dynamic  Components 

If  a  record  component  is  a  record  or  an  array,  the  size  of  the  component  may 
need  to  be  computed  at  run  time  and  may  depend  on  the  discriminants  of  the 
record.  These  components  are  called  dynamic  components. 

Example  (Record  with  dynamic  components): 
type  U.RNG  is  range  0 . . 255 ; 

type  UC.ARRAY  is  array (U.RNG  range  <>)  of  INTEGER; 

—  The  type  GRAPH  has  two  dynamic  components:  X  and  Y. 

type  GRAPH  (X.LEN,  Y.LEN;  U.RNG)  is 
record 

X  :  UC.ARRAY (1  ..  X.LEN); 

—  The  size  of  X  depends  on  X.LEN 
Y  :  UC.ARRAY (1  ..  Y.LEN); 

—  The  size  of  Y  depends  on  Y.LEN 

end  record; 

type  DEVICE  is  (SCREEN.  PRINTER); 
type  COLOR  is  (GREEN,  RED,  BLUE); 

0  :  U.RNG; 
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—  The  type  PICTURE  has  two  dynamic  components:  R  and  T. 

type  PICTURE  (N  :  U.RNG;  D  :  DEVICE)  is 
record 

R  :  GRAPH(N,N);  —  The  size  of  R  depends  on  N 
T  ;  GRAPH(Q,Q);  —  The  size  of  T  depends  on  Q 
case  D  is 

when  SCREEN  =>  C  :  COLOR; 
when  PRINTER  =>  null ; 
end  case; 
end  record; 

Any  component  that  is  placed  after  a  dynamic  component  has  an  offset 
that  cannot  be  evaluated  at  compile  time  and  is  thus  indirect.  To  minimize 
the  number  of  indirect  components,  the  compiler  groups  the  dynamic 
components  and  places  them  at  the  end  of  the  record.  Due  to  this  strategy, 
the  only  indirect  components  are  dynamic  components.  However,  all  dynamic 
components  are  not  necessarily  indirect.  The  compiler  can  usually  compute  the 
offset  of  the  first  dynamic  component  and  thus  it  becomes  a  direct  component. 
Any  additional  dynamic  components  are  then  indirect  components. 
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A  pictorial  example  of  the  data  layout  for  the  record  type  PICTURE  is  shown  in 
Figure  4-3. 
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Figure  4>3.  Example  of  a  Data  Layout 
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F  4.8.9  Representation  of  the  Offset  of  an  Indirect  Component 

The  offset  of  an  indirect  component  is  always  expressed  in  storage  units,  which 
for  the  HP  9000  Series  600,  700,  and  800  Computer  System  are  bytes.  The 
space  that  the  compiler  reserves  for  the  offset  of  an  indirect  component  must 
be  large  enough  to  store  the  maximum  potential  offset.  The  compiler  will 
choose  the  size  of  an  offset  component  to  be  either  an  8-,  16-,  or  32-bit  object. 
It  is  possible  to  further  reduce  the  size  in  bits  of  this  component  by  specifying 
it  in  a  component  clause. 

If  C  is  the  name  of  an  indirect  component,  the  offset  of  this  component  can 
be  denoted  in  a  component  clause  by  the  implementation-generated  name 
C’ OFFSET. 


Example  (Record  representation  clause  for  the  type  GRAPH) 

for  GRAPH  use 
record 

X. LEN  at  0  range  0..7; 

Y. LEN  at  1  range  0..7; 

X’ OFFSET  at  2  range  0..15; 

end  record; 

--  The  bit  range  for  the  implicit  component 
--  X’OFFSET  could  have  been  specified  as  0..11 
—  This  would  make  access  to  X  much  slower 


In  this  example  we  have  used  a  component  clause  to  specify  the  location  of 
an  offset  for  a  dynamic  component.  In  this  example  the  compiler  will  choose 
Y  to  be  the  first  dynamic  component  and  as  such  it  will  have  a  static  offset. 
The  component  X  will  be  placed  immediately  after  the  end  of  component  Y  by 
the  compiler  at  run  time.  .4t  run  lime  the  compiler  will  store  the  offset  of  this 
location  in  the  field  X' OFFSET.  Any  references  to  X  will  have  additional  code  to 
compute  the  run  time  address  of  X  using  the  X’OFFSET  field.  References  to  Y 
will  be  direct  references. 
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F  4.8.10  The  Implicit  Component  RECORD.SIZE 

This  implicit  component  is  created  by  the  compiler  whenever  a  record  with 
discriminants  has  a  variant  part  and  the  discriminant  that  defines  the  variant 
part  has  a  default  expression  (that  is,  a  record  type  that  possibly  could  be 
unconstrained.)  The  component  ’RECORD.SIZE  contains  the  size  of  the  storage 
space  required  to  represent  the  current  variant  of  the  record  object.  Note  that 
the  actucil  storage  allocated  for  the  record  object  may  be  more  than  this. 

The  value  of  a  RECORD.SIZE  component  may  denote  a  number  of  bits  or  a 
number  of  storage  units  (bytes).  In  most  cases  it  denotes  a  number  of  storage 
units  (bytes),  but  if  any  component  clause  specifies  that  a  component  of  the 
record  type  has  an  offset  or  a  size  that  cannot  be  expressed  using  storage  units, 
the  value  designates  a  number  of  bits. 

The  implicit  component  RECORD.SIZE  must  be  large  enough  to  store  the 
maximum  size  that  the  record  type  can  attain.  The  compiler  evaluates  this 
size,  calls  it  MS,  and  considers  the  type  of  RECORD.SIZE  to  be  an  anonymous 
integer  type  whose  range  is  0  . .  MS. 

If  R  is  the  name  of  a  record  type,  this  implicit  component  can  be  denoted  in  a 
component  clause  by  the  implementation-generated  name  R’ RECORD.SIZE. 


F  4.8.11  The  Implicit  Component  VARIANT.INDEX 

This  implicit  component  is  created  by  the  compiler  whenever  the  record  type 
has  a  variant  part.  It  indicates  the  set  of  components  that  are  present  in  a 
record  object.  It  is  used  when  a  discriminant  check  is  to  be  done. 

Within  a  variant  part  of  a  record  type,  the  compiler  numbers  component  lists 
that  themselves  do  not  contain  a  variant  part.  These  numbers  are  the  possible 
values  for  the  implicit  component  VARIANT.INDEX.  The  compiler  uses  this 
number  to  determine  which  components  of  the  variant  record  are  currently 
valid. 


4.44  F  4.  Type  Representation 


Example  (Record  with  a  variant  part): 

type  VEHICLE  is  (AIRCRAFT,  ROCKET,  BOAT,  CAR); 

type  DESCRIPTION (  KIND  :  VEHICLE  :=  CAR)  is 
record 

SPEED  :  INTEGER; 
case  KIND  is 

when  AIRCRAFT  I  CAR  => 

WHEELS  :  INTEGER; 
case  KIND  is 

when  AIRCRAFT  =>  --  VARIANT.INDEX  is  1 

WINGSPAN  :  INTEGER; 

when  others  =>  --  VARIANT.INDEX  is  2 

null; 
end  case; 

when  BOAT  *>  —  VARIANT.INDEX  is  3 

STEAM  :  BOOLEAN; 

when  ROCKET  =>  —  VARIANT.INDEX  is  4 

STAGES  :  INTEGER; 
end  case; 
end  record; 

In  the  above  example,  the  \'alue  of  the  variant  index  indicates  which  of  the 
components  are  present  in  the  record  object;  these  components  are  summarized 
in  the  table  below. 


Variant  Index 

Legal  Comf«onents 

1 

KIND,  SPEED,  WHEELS,  WINGSPAN 

2 

KIND,  SPEED,  WHEELS 

3 

KIND,  SPEED,  STEAM 

4 

KIND,  SPEED,  STAGES 
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The  implicit  component  VARIANT.INDEX  must  be  large  enough  to  store  the 
number  of  component  lists  that  do  not  contain  variant  pzirts.  The  compiler 
evaluates  this  size,  calls  it  VS,  and  considers  the  type  of  VARIANT_INDEX  to  be 
an  anonymous  integer  type  whose  range  is  0  . .  VS. 

If  R  is  the  name  of  a  record  type,  this  implicit  component  can  be  denoted  in  a 
component  clause  by  the  implementation-generated  name  R'VARIANT_INDEX. 


F  4.8.12  The  Implicit  Component  ARRAY.DESCRIPTOR 

An  implicit  component  of  this  kind  is  associated  by  the  compiler  with  each 
record  component  whose  type  is  an  array  that  has  bounds  that  depend  on  a 
discriminant  of  the  record. 

The  structure  and  contents  of  the  implicit  component  ARRAY.DESCRIPTOR  are 
not  described  in  this  manual.  Nevertheless,  if  you  are  interested  in  specifying 
the  location  of  a  component  of  this  kind  in  a  component  clause,  you  can  obtain 
the  size  of  the  component  by  supplying  the  -S  option  (Assembly  Option)  to  the 
ada(l)  command. 

If  C  is  the  name  of  a  record  component  that  conforms  to  the  above  definition, 
this  implicit  component  can  be  denoted  in  a  component  clause  by  the 
implementation-generated  name  C’ ARRAY.DESCRIPTOR. 


F  4.8.13  The  Implicit  Component  RECORD.DESCRIPTOR 

An  implicit, component  of  this  kind  may  be  associated  by  the  compiler  when  a 
record  component  is  a  record  type  that  has  components  whose  size  depends  on 
a  discriminant  of  the  outer  record. 

The  structure  and  content  of  the  implicit  component  RECORD.DESCRIPTOR  are 
not  described  in  this  manual.  Nevertheless,  if  you  are  interested  in  specifying 
the  location  of  a  component  of  this  kind  in  a  component  clause,  you  can  obtain 
the  size  of  the  component  by  applying  the  -S  option  (Assembly  Option)  to  the 
ada(T)  command. 
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If  C  is  the  name  of  a  record  component  that  conforms  to  the  above  definition, 
this  implicit  component  caji  be  denoted  in  a  component  clause  by  the 
implementation-generated  name  C  *  RECORD.DESCRIPTOR. 


F  4.8.14  Suppression  of  Implicit  Components 

Ada  provides  the  capability  of  suppressing  the  implicit  components 
RECORD.SIZE  and  VARIANT.INDEX  from  a  record  type.  This  can  be  done  using 
an  implementation  defined  pragma  called  IMPROVE. 


Syntax 

pragma  IMPROVE  (  TIME  I  SPACE  ,  [ON  =>]  record-type -name  ) ; 


The  first  argument  specifies  whether  TIME  or  SPACE  is  the  primary  criterion  for 
the  choice  of  representation  of  the  record  type  that  is  denoted  by  the  second 
argument. 

If  TIME  is  specified,  the  compiler  inserts  implicit  components  as  described 
above.  This  is  the  default  behavior  of  the  compiler.  If  SPACE  is  specified, 
the  compiler  only  inserts  a  VARIANT.INDEX  component  or  a  RECORD_SIZE 
component  if  a  component  clause  for  one  of  these  components  was  supplied. 

If  the  record  type  has  no  record  representation  clause,  both  components  will 
be  suppressed.  Thus,  a  record  representation  clause  can  be  used  to  keep  one 
implicit  Component  while  suppressing  the  other. 

•  A  pragma  IMPROVE  that  applies  to  a  given  record  type  can  occur  anywhere  that 
a  record  representation  clause  is  allowed  for  this  type. 
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F  4.8.15  Size  of  a  Record  Type  or  Subtype 

The  compiler  generally  will  round  up  the  size  of  a  record  type  to  a  whole 
number  of  storage  units  (bytes).  If  the  record  type  has  a  component  clause 
that  specifies  a  record  component  that  cannot  be  expressed  in  storage  units, 
the  compiler  will  not  round  up  and  instead  the  record  size  will  be  expressed  as 
an  exact  number  of  bits. 

The  size  of  a  constrained  record  type  is  obtained  by  adding  the  sizes  of  its 
components  and  the  sizes  of  its  gaps  (if  any).  The  size  of  a  constrained  record 
will  not  be  computed  at  compile  time  if; 

■  The  record  type  has  non-static  constraints. 

■  A  component  is  an  array  or  record  and  its  size  cannot  be  computed  at 
compile  time  (that  is,  if  the  component  has  non-static  constraints.) 

The  size  of  an  unconstrained  record  type  is  the  largest  possible  size  that 
the  unconstrained  record  type  could  assume,  given  the  constraints  of  the 
discriminant  or  discriminants.  If  the  size  of  any  component  cannot  be 
evaluated  exactly  at  compile  time,  the  compiler  will  use  tlie  maximum  size  that 
the  component  could  possibly  assume  to  compute  the  size  of  the  unconstrained 
record  type. 

A  size  specification  applied  to  a  record  type  has  no  effect.  The  only  size  that 
the  compiler  will  accept  in  such  a  length  clause  is  the  usual  size.  Nevertheless, 
such  a  length  clause  can  be  used  to  verify  that  the  layout  of  a  record  is  as 
expected  by  the  application. 
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F  4.8.16  Size  of  an  Object  of  a  Record  Type 

A  record  object  of  a  constrained  record  type  has  the  same  size  as  its  base  type. 

A  record  object  of  an  unconstrained  record  type  has  the  same  size  as  its  batse 
type  if  this  size  is  less  than  or  equal  to  24576  bytes.  The  size  of  the  base  type 
is  the  lairgest  possible  size  that  the  unconstrained  record  type  could  assume, 
given  the  constraints  of  the  discriminant(s).  If  the  size  of  the  base  type  is 
larger  than  24576  bytes,  the  record  object  only  has  the  size  necessary  to  store 
its  current  value.  Storage  space  is  then  allocated  and  deallocated  dynamically 
based  on  the  current  value  of  the  discriminant  or  discriminants. 


F  4.8.17  Alignment  of  a  Record  Subtype 

When  a  record  type  does  not  have  a  record  representation  clause,  or  when  a 
record  type  has  a  record  representation  clause  without  an  alignment  clause, 
the  record  type  is  word-aligned  to  the  maximum  alignment  required  by  any 
component  of  the  record  (8, 16,  32,  or  64  bits).  Any  subtypes  of  a  record  type 
also  have  the  same  alignment  as  their  base  type. 

For  a  record  type  that  has  a  record  representation  clause  with  an  alignment 
clause,  any  subtypes  of  this  record  type  also  obey  the  alignment  clause. 

An  alignment  clause  can  specify  that  a  record  type  is  byte,  half-word,  word,  or 
double-word  aligned  (specified  as  1,  2,  4,  or  8  bytes).  Ada  does  not  support 
alignments  larger  than  an  8-byte  alignment. 
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F  4.9  Data  Allocation 

This  section  explains  how  data  objects  are  allocated  by  the  HP  Ada  compiler 
for  the  HP  9000  Series  600,  700,  and  800  Computer  System. 

Data  objects  are  allocated  into; 

■  A  stack  frame. 

■  The  global  data  area. 

■  The  heap. 

or  have  no  storage  allocated  to  them. 

A  stack  frame  is  used  for  objects  declared  within  a  subprogram  or  task  body, 
or  within  a  declare  block.  The  stack  frame  contains  the  data  objects  that  are 
dynamic  if  each  invocation  of  the  subprogram  or  block  creates  a  new  data 
object.  Each  object  allocated  in  a  stack  frame  has  a  lifetime  that  begins  after 
the  elaboration  of  the  subprogram  or  block  enclosing  the  object  and  ends  after 
the  subprogram  or  the  block  is  exited. 

The  global  data  area  is  used  for  objects  declared  in  library  level  packages, 
either  in  the  specification  or  in  the  body.  The  global  data  area  contains  the 
data  objects  that  are  allocated  in  a  static  manner.  Each  object  allocated  in  the 
global  data  area  has  a  permanent  lifetime.  The  global  data  area  is  allocated  in 
the  $DATA$  segment  of  the  HP-UX  object  file  (see  a. out. 800 (4)). 

The  heap  is  used  for  objects  that  are  created  by  an  Ada  allocator  as  well  as 
objects  created  via  indirect  allocation.  Storage  for  task  objects,  including  the 
task  stack,  are  also  allocated  into  the  heap.  The  heap  contains  the  data  objects 
that  are  dynamic  in  the  broadest  sense.  Each  object  allocated  in  the  heap  has 
a  lifetime  that  begins  after  the  allocator  operation  and  ends  only  when  an 
implicit  or  explicit  deallocator  operation  is  performed.  The  heap  is  allocated 
using  the  sbrk(2)  system  call. 
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For  constants  that  are  scalar  in  type,  no  storage  is  allocated  or  used.  The 
values  are  stored  in  a  compile-time  data  structure.  Because  these  scalar 
constants  do  not  have  an  allocation  address,  it  is  illegal  to  refer  to  their  address 
(using  the  attribute  ’ADDRESS)  or  to  supply  an  address  for  them  (using  an 
address  clause.)  Constants  that  are  aggregates  or  non-scalar  are  allocated  into 
one  of  the  above  three  locations. 

Objects  that  are  created  by  the  compiler,  such  as  temporaries,  also  obey  the 
above  rules. 
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F  4.9.1  Direct  Allocation  versus  Indirect  Allocation 

The  HP  Ada  compiler  determines  whether  to  allocate  each  object  directly  in 
the  frame  or  in  the  global  data  area,  or  to  allocate  it  dynamically  in  the  heap 
and  access  it  indirectly  via  a  pointer.  These  two  modes  are  czdled  direct  and 
indirect,  respectively.  The  determination  is  based  on  the  object’s  size  or  its 
maximum  possible  size.  An  allocation  map  will  list  the  size  of  all  objects  and 
can  be  produced  by  using  the  -S  assembly  option. 

Note  that  objects  of  the  unconstrained  type  STRING,  including  those  returned 
by  functions  that  return  the  type  STRING,  are  allocated  in  the  heap. 

F  4.9.2  Object  Deallocation 

This  section  describes  compiler-generated  objects,  programmer-generated 
objects,  and  program  termination. 

F  4.9.2.1  Compiler>Generated  Objects 

All  objects  that  the  compiler  chooses  to  represent  in  an  indirect  form  will 
automatically  be  freed  and  their  storage  reclaimed  when  leaving  the  scope  in 
which  the  objects  are  declared.  Moreover,  all  compiler- generated  temporaries 
that  are  allocated  on  the  heap  in  a  scope  will  be  deallocated  upon  leaving  the 
scope.  These  compiler  temporaries  are  often  generated  by  such  operations 
as  function  calls  returning  unconstrained  arrays,  or  by  using  the  STRING 
concatenation  operator  (4).  By  enclosing  the  statements  in  a  begin  . . .  end 
block,  you  can  force  the  heap  to  reclaim  the  temporaries  associated  with  any 
statement. 

The  storage. associated  with  a  task  object,  including  its  stack  space,  is 
automatically  freed  when  the  task  terminates. 
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F  4.9.2.2  Programmer- Generated  Objects 

Whether  the  storage  for  an  object  created  with  an  Ada  allocator  is  reclaimed 
depends  on  where  the  access  type  is  declared. 

For  access  types  declared  in  a  nested  or  non-library  level  scope,  all  objects 
created  with  an  Ada  allocator  will  automatically  be  freed  and  their  storage 
reclaimed  when  leaving  the  scope  in  which  the  type  was  declared.  Thus, 
pragma  CONTROLLED  is  effectively  applied  to  all  access  types  by  default.  Upon 
exiting  a  scope  that  declares  an  access  type,  the  lifetime  of  objects  of  this 
access  type  expires  and  the  storage  can  be  reclaimed  safely. 

For  access  types  declared  in  a  library  level  scope  or  with  library  package 
visibility,  objects  that  are  created  using  a  type  declared  in  a  library  level 
package  will  not  be  freed  by  the  Ada  Runtime  System.  The  compiler  cannot 
determine  the  lifetime  of  the  object  and  thus  must  assume  that  a  future 
reference  to  the  object  could  occur  at  any  time.  For  these  kinds  of  objects,  it  is 
the  programmer’s  responsibility  to  reclaim  their  storage  through  the  careful  use 
of  UNCHECKED.DEALLOCATION. 

F  4.9.2.3  Program  Termination 

All  memory  used  by  a  program,  including  code,  global  data,  I/O  buffers,  and  so 
on.  is  released  when  the  program  terminates  and  returns  to  HP-UX.  This  is  the 
standard  behavior  of  any  program  under  HP-UX. 
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F  4.9.3  Dynamic  Memory  Management 

This  section  explains  how  dynamic  memory  is  managed  by  the  Ada  Runtime 
System. 

F  4.9.3.1  Collections  of  Objects 

Every  access  type  has  a  corresponding  collection  of  objects  associated 
with  it.  Each  use  of  an  allocator  queries  the  corresponding  collection  and 
then  reserves  the  correct  amount  of  space  within  the  heap.  Each  use  of 
UNCHECKED.DEALLOCATION  updates  the  collection  data  structures  and  effectively 
gives  back  the  space  for  future  use. 

The  size  of  the  space  taken  from  the  heap  depends  on; 

■  The  designated  type. 

■  The  access  value  type. 

■  Possibly,  for  an  unconstrained  record  access  type,  the  supplied  value  of  the 
discriminant  or  discriminants  either  when  the  object  is  created  or  again  when 
a  new  value  is  given  to  the  object. 

The  effective  size  of  the  object  can  be  obtained  using  the  predefined  attribute 
’SIZE.  For  an  unconstrained  array  access  type,  a  descriptor  is  added  that  holds 
the  unconstrained  actual  dimension  or  dimensions  with  the  actual  size  of  the 
array;  thus,  the  descriptor  size  is  the  sum  of  the  size  cont2iiner  (generally  4 
bytes)  and  all  the  actual  constraints  (array  bounds)  implemented  the  same  way 
as  their  index  type  (either  1.  2,  or  4  bytes  each). 

The  heap  manager  applies  the  following  rules  to  each  object: 

■  The  size  of  the  object  is  rounded  up  to  an  even  number  of  bytes. 

■  The  minimum  size  is  12  bytes.  Thus,  if  the  object  is  less  than  12  bytes,  it  is 
increased  to  12  bytes. 

■  To  the  above  size,  the  following  is  added:  a  8-byte  descriptor  if  the  collection 
is  global  (is  declared  within  a  library  level  package)  or  a  40-byte  descriptor 

if  the  collection  is  in  a  nested  scope  (declared  within  a  procedure  or  task 
body). 


4-54  F  4.  Type  Representation 


A  speciaJ  rule  applies  for  collections  where  the  objects  of  the  designated  type 
are  of  static  size  and  are  smaller  than  64  bytes.  Instead  of  allocating  one 
object  at  a  time  within  the  heap,  blocks  of  several  objects  are  allocated.  The 
size  of  the  block  is  either  128  bytes  or  16  times  the  object  size  plus  10  bytes, 
whichever  is  greater.  To  the  size  of  this  block,  the  heap  manager  applies  the 
above  rules;  that  is,  the  heap  manager  adds  either  a  8-  or  40-byte  descriptor. 

When  a  collection  size  is  specified  using  a  length  clause  for  an  access  type  (that 
is,  for  T’ST0RAGE_SIZE  use  <nnn>),  the  heap  manager  allocates  a  single  block 
of  the  specified  size.  The  size  of  this  block  will  be  exactly  the  size  specified  in 
the  length  clause.  Individual  objects  will  then  be  allocated  from  this  block. 

The  minimum  size  of  an  individual  object  allocated  from  this  block  is  four 
bytes.  Whenever  UNCHECKED.DEALLOCATION  is  performed  on  an  object,  the 
collection  will  add  the  object  to  the  free  list  aissociated  with  the  collection. 

This  free  list  is  maintained  as  a  linked  list  of  pointers  contained  directly  within 
the  collection.  No  additional  storage  is  required  to  maintain  the  free  list.  When 
space  in  the  collection  is  exhausted,  the  exception  STOEAGE.ERROR  is  raised. 

F  4.9.3.2  Global  Dynamic  Objects 

A  global  dynamic  object  is  a  user-declared  object  whose  size  is  not  known  until 
e.xeculion  time  and  is  declared  within  a  library  package  (in  a  specification  or 
body  including  nested  packages  and  blocks,  but  not  .  ubprograms  or  tasks.) 

The  compiler  also  considers  an  object  as  dynamic  if  the  size  is  bigger  than  1024 
bytes,  even  if  this  size  is  known  statically  at  compile  time.  The  compiler  also 
considers  any  object  as  static  if  the  maximum  size  is  sma’ler  than  128  bytes, 
even  if  this  size  must  be  dynamically  computed  at  execution  time. 

All  such  global  dynamic  objects  are  allocated  within  the  heap.  The  size  of 
these  objects  can  be  obtained  using  the  predefined  attribute  'SIZE  and  the 
heap  manager  applies  the  same  rules  to  them  as  it  does  for  collections  of 
objects,  as  described  in  section  “F  4. 9.3.1  Collections  of  Objects”. 
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F  4.9.3.3  Local  Objects 

Local  objects,  declared  within  a  subprogram  or  task,  are  normally  allocated  in 
the  stack.  This  is  done  either  in  the  frame  associated  with  the  subprogram  or 
task  execution,  or  dynamically  on  top  of  the  stack  at  the  time  of  elaboration  of 
the  object  declaration  when  the  size  of  the  object  is  dynamic. 

The  heap  is  used  for  an  unconstrained  record  if  the  object  discriminant 
or  discriminants  can  be  changed  during  the  lifetime  of  the  object.  This 
discriminant  change  has  a  potentially  large  effect  on  the  object  size.  In  this 
case,  the  object  is  allocated  in  the  heap,  and  when  the  discriminant  changes,  a 
new  space  of  the  desired  size  is  allocated  and  the  old  space  is  given  back  to  the 
heap. 

The  heap  manager  applies  the  same  rules  for  object  size  as  described  in 
“F  4. 9.3.1  Collections  of  Objects”. 

F  4.9.3.4  Temporary  Objects 

During  code  execution,  it  is  sometimes  necessary  to  take  some  memory  space 
from  the  heap  to  hold  temporary  object  values.  This  only  happens  when  the 
memory  size  is  not  known  at  compiler  time,  or  memory  size  is  big  enough 
(more  than  128  bytes)  to  be  considered  dynamic  rather  than  static  for  this 
implementation. 

The  following  cases  are  possible: 

■  Function  results  that  are  of  a  dynamic  size. 

■  Evaluation  of  large  aggregates. 

■  Operations  on  dynamic  arrays  (such  as  catenation  of  object  of  type  STRING; 
also  the  predefined  operators  and,  or,  xor,  and  not  used  on  dynamic  Boolean 
arrays). 

■  Evaluation  of  the  predefined  attribute  ’IMAGE. 
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F  4.9.3.5  Reclaiming  Heap  Storage 

Heap  storage  is  reclaimed  as  follows: 

■  For  the  collection  of  an  access  type,  all  storage  allocated  is  returned 
upon  exiting  the  scope  in  which  access  type  was  declared.  Reclaiming 
occurs  whether  the  exit  is  normal  or  abnormal  (that  is,  due  to  exception 
propagation.) 

■  The  storage  of  a  task,  (including  its’  stack)  is  reclaimed  when  the  task 
terminates. 

■  For  an  object  passed  to  an  instance  of  the  generic  procedure 
UNCHECKED  .DEALLOCATION,  the  storage  associated  with  the  object  is 
reclaimed  immediately. 

■  For  a  temporary  object,  storage  is  returned  no  later  than  on  exit  from  the 
scope  (subprogram  or  block)  that  contained  the  allocation  of  the  temporary 
object. 

For  objects  of  an  access  type  declared  in  a  library  package,  automatic 
reclaiming  is  not  performed.  This  would  require  automatic  garbage 
collection  with  its’  inherent  overhead  at  runtime.  You  should  perform 
UNCHECKED.DEALLOCATION  to  reclaim  this  storage. 

Reclaimed  heap  storage  is  managed  internally  by  the  Ada  Runtime  System. 
Such  memory  is  never  relecised  back  to  HP-UX  using  the  sbrk(l)  system  call. 
Reclaimed  heap  storage  is  available  for  the  Ada  Runtime  System  to  reuse; 
however,  to  the  HP-UX  kernel,  it  appears  that  the  memory  is  still  in  use  by  the 
Ada  Runtime  System. 
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F  5.  Names  for  Predefined  Library  Units 


Names  that  are  available,  but  should  be  avoided  if  you  want  access  to  packages 
that  are  provided  by  Hewlett-Packard; 

ELEMENTARY.FUNCTIONS.EXCEPTIONS 

GENERIC.ELEMENTARY.FUNCTIONS 

MATH.LIB 

MATH.LIB.LIBM 

SYSTEM.ENVIRONMENT 


The  above  packages  are  documented  in  the  Ada  User’s  Guide. 
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F  6.  Address  Clauses 


This  chapter  describes  the  available  address  clauses. 


F  6.1  Objects 

An  address  clause  can  be  used  to  specify  an  address  for  an  object  as  described 
in  the  Ada  RM,  section  13.5.  When  such  a  clause  applies  to  an  object,  no 
storage  is  allocated  for  it  in  the  program  generated  by  the  compiler.  Storage 
for  the  object  must  be  allocated  for  the  object  outside  of  the  Ada  program  unit 
unless  the  address  is  a  memory  mapped  hardware  address.  The  Ada  program 
accesses  the  object  by  using  the  address  specified  in  the  address  clause. 

An  address  clause  is  not  allowed  for  unconstrained  records  whose  maximum 
size  can  be  greater  than  24576  bytes. 

Note  that  the  function  SYSTEM. VALUE,  defined  in  the  package  SYSTEM,  is 
available  to  convert  a  STRING  value  into  a  value  of  type  SYSTEM .  ADDRESS  (see 
section  “F  3.1  The  Package  SYSTEM”  for  details).  Note  that  the  IMPORT 
attribute  is  available  to  provide  the  address  of  an  external  svmbol  (see  section 
2.2  Attribute  SYSTEM.ADDRESS’IMPORT”  for  details). 
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F  6.6  Data  Objects 

An  address  clause  can  specify  the  address  for  an  object  as  described  in  the 
Ada  RM,  section  13.5.  The  address  supplied  must  be  either  an  integer 
constant  or  the  value  returned  by  the  implementation-defined  attribute 
SYSTEM.  ADDRESS ’IMPORT.  This  attribute  is  defined  to  return  a  reference 
value  that  can  be  used  as  the  address  of  an  external  static  data  object.  This 
attribute  takes  two  parameters:  the  language  and  the  name  of  the  external 
data  object.  Both  of  these  parameters  are  Ada  strings. 

Example 

IMPORT.OBJ:  INTEGER; 

for  IMPORT.OBJ  use  at  SYSTEM. ADDRESS’ IMPORT ( "c" .  "c.obj"); 

MEMORY.MAPPED.OBJ:  INTEGER; 

for  MEMORY.MAPPED.OBJ  use  at  16#6FFF_0400# ; 

See  section  “F  2.2  Attribute  SYSTEM. ADDRESSTMPORT”  for  more  details. 


F  6.7  Task  Entries 

An  address  clause  can  be  supplied  for  an  .\da  task  entry.  The  actual  address  of 
the  .4da  task  entry  is  not  bound  to  the  value  supplied  by  the  address  clause. 
Instead,  this  kind  of  address  clause  is  used  to  provide  the  interrupt  entry 
mechanism  (see  section  “F  12.  Interrupt  Entries"  for  details). 
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F  7.  Restrictions  on  Unchecked  Type 
Conversions 


The  following  limitations  apply  to  the  use  of  UNCHECKED.CONVERSION: 

■  Unconstrained  arrays  are  not  allowed  as  target  types. 

■  Unconstrained  record  types  without  defaulted  disciminants  are  not  allowed  as 
target  types. 

■  .\ccess  types  to  unconstrained  arrays  or  unconstrained  strings  are  not  allowed 
as  source  or  target  types. 

■  If  the  source  and  target  types  are  each  scalar  types,  the  sizes  of  the  types 
must  be  equal. 

■  If  the  source  and  target  types  are  each  access  types,  the  sizes  of  the  objects 
that  the  types  denote  must  be  equal. 

■  If  the  source  or  target  type  is  a  composite  type,  the  sizes  do  not  have  to  be 
equal.  See  the  warning  below  for  more  details. 

If  the  source  and  target  types  are  each  of  scalar  or  access  types  or  if  they  are 

both  of  composite  type  with  the  same  static  size,  the  effect  of  the  function  is  to 

return  the  operand. 

Jn  other  cases,  the  effect  of  unchecked  conversion  can  be  considered  as  a  copy- 

operation. 
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F  8.  Implementation-Dependent  Input-Output 


Characteristics 

This  chapter  describes  the  I/O  characteristics  of  Ada  on  the  HP  9000  Series 
600,  700,  and  800  computers.  Ada  handles  I/O  with  packages,  which  are 
discussed  in  section  “F  8.1  Ada  I/O  Packages  for  External  Files”.  File  types 
are  described  in  section  “F  8.1.3  Standard  Implementation  of  External  Files” 
and  the  FORM  parameter  is  discussed  in  section  “F  8.2  The  FORM  Parameter” 


F  8.1  Ada  I/O  Packages  for  External  Files 

In  Ada,  I/O  operations  are  considered  to  be  performed  on  objects  of  a  certain 
file  type  rather  than  directly  on  external  files.  An  external  file  is  anything 
external  to  the  program  that  can  produce  a  value  to  be  read  or  receive  a  value 
to  be  written.  In  .\da,  Vcdues  transferred  to  and  from  a  given  file  must  all  be  of 
the  same  type. 

Generally,  the  term  file  object  refers  to  an  Ada  file  of  a  certain  file  type, 
whereas  a  physical  manifestation  is  known  as  an  external  file.  An  external  file 
■is  characterized  by: 

■  Its  NAME,  which  is  a  string  defining  a  legal  pathname  for  an  external  file  on 
the  underlying  operating  system.  HP-UX  is  the  underlying  operating  system 
for  Ada.  The  rules  that  govern  legal  pathnames  for  external  files  in  Ada 
programs  are  the  same  as  those  that  govern  legal  pathnames  in  HP-UX.  See 
section  ‘'F  8.1.2  Correspondence  between  Externa]  Files  and  HP-UX”  for 
details. 

■  Its  FORM,  which  allows  you  to  supply  implementation-dependent  information 
about  the  external  file  characteristics. 
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F  8.1.1  Implementation-Dependent  Restrictions  on  I/O  Packages 

The  upper  bound  for  index  values  in  DIRECT_I0  and  for  line,  column,  and  page 
numbers  in  TEXT_I0  is: 

COUNT ’LAST  =  2**31  -  1 

The  upper  bound  for  field  widths  in  TEXT.IO  is: 

FIELD ’LAST  =  255 


F  8.1.2  Correspondence  between  External  Files  and  HP-UX 

Files 

When  Ada  I/O  operations  are  performed,  data  is  read  from  and  written  to 
external  files.  Each  external  file  is  implemented  as  a  standard  HP-UX  file. 
However,  before  an  external  file  can  be  used  by  an  Ada  program,  it  must  be 
associated  with  a  file  object  belonging  to  that  program.  This  association  is 
achieved  by  supplying  the  name  of  the  file  object  and  the  name  of  the  external 
file  to  the  procedures  CREATE  or  OPEN  of  the  predefined  1/0  packages.  Once  the 
association  has  been  made,  the  external  file  can  be  read  from  or  written  to  with 
the  file  object.  Note  that  for  SEQUENTIAL.IO  and  DIRECT.IO.  you  must  first 
instantiate  the  generic  package  to  produce  a  non-generic  instance.  Then  you 
can  use  the  CREATE  or  OPEN  procedure  of  that  instance.  The  example  at  the 
end  of  this  section  illustrates  this  instantiation  process. 

The  name  of  the  external  file  can  be  either  of  the  following: 

m  an  HP-UX  pathname 

■  a  null  string  (for  CREATE  only) 

The  exception  USE.ERROR  is  raised  by  the  procedure  CREATE  if  the  specified 
external  file  cannot  be  created.  The  exception  USE.ERROR  is  also  raised  by  the 
procedure  OPEN  if  you  have  insufficient  access  rights  to  the  file. 

If  the  name  is  a  null  string,  the  associated  external  file  is  a  temporary  file 
created  using  the  HP-UX  facility  tmpnamO).  This  external  file  will  cease  to 
exist  upon  completion  of  the  program. 
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IFILE  :  INTIO.FILE.TYPE; 


IVALUE  :  INTEGER  :=  0;  —  Ordinary  integer  object 

begin 

INTIO. CREATE  (  FILE  =>  IFILE, 

—  Ada  file  is  IFILE 
MODE  =>  INTIO . OUT.FILE , 

—  MODE  allows  WRITE  only 
NAME  =>  "rnyfile" 

—  file  name  is  "myfile" 

): 

TEXT.IO.PUT.LINE  ("Created  :  "  ft 

INTIO. NAME  (IFILE)  ft 
" ,  mode  is  "  ft 
INTIO . FILE.MODE ' IMAGE 

(INTIO. MODE  (IFILE))  ); 

INTIO. WRITE  (IFILE,  21);  —  Write  the  integer  21  to  the  file 

—  Close  the  external  file 
INTIO. CLOSE  (  FILE  =>  IFILE); 

TEXT.IO.PUT.LINEC'Closed  file"); 

INTIO. OPEN  (  FILE  =>  IFILE, 

--  Ada  file  is  IFILE 
MODE  =>  INTIO. INOUT.FILE, 

—  MODE  allows  READ  and  WRITE 
NAME  =>  "myfile" 

—  file  name  is  "myfile" 

): 

TEXT.IO.PUT.LINE  ("Opened  :  "  ft 

INTIO. NAME  (IFILE)  ft 
" ,  mode  is  "  ft 
INTIO. FILE.MODE’ IMAGE 

(INTIO. MODE  (IFILE))  ); 
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Note 


The  Ada  development  system  manages  files  internally  so 
that  names  involving  symbolic  links  (see  InCD)  are  mapped 
back  to  the  actual  rooted  path.  Consequently,  when  the  Ada 
development  system  interacts  with  files  involving  symbolic 
links,  the  actual  rooted  pathname  may  be  mentioned  in 
informational  or  error  messages  rather  than  the  symbolic  name. 


F  8.1.3  Standard  Implementation  of  External  Files 

External  files  have  a  number  of  implementation-dependent  characteristics,  such 
ais  their  physical  organization  and  file  access  rights.  It  is  possible  to  customize 
these  characteristics  through  the  FORM  parameter  of  the  CREATE  and  OPEN 
procedures,  described  fully  in  section  “F  8.2  The  FORM  Parameter^.  The 
default  of  FORM  is  the  null  string. 

The  next  three  subsections  describe  the  Ada  implementation  of  these  three 
types  of  external  files:  SEQUENTIAL.IO,  DIRECT.IO,  and  TEXT.IO  files. 


F  8.1.3.1  SEQUENTIAL.tO  Files 

A  SEQUENTIAL.IO  file  is  a  sequence  of  elements  that  are  transferred  in  the 
order  of  their  appearance  to  or  from  an  external  file.  Each  element  in  the  file 
contains  one  object  of  the  type  that  SEQUENTIAL.IO  was  instantiated  on.  .A.11 
objects  in  the  file  are  of  this  same  type.  An  object  stored  in  a  SEQUENTIAL.IO 
file  has  exactly  the  same  binary  representation  as  an  Ada  object  in  the 
executable  program 

The  information  placed  in  a  SEQUENTIAL.IO  file  depends  on  whether  the  type 
used  in  the  instantiation  is  a  constrained  type  or  an  unconstrained  type. 

For  a  SEQUENTIAL.IO  file  instantiated  with  a  constrained  type,  each  element 
is  simply  the  object.  The  objects  are  stored  consecutively  in  the  file  without  *- 
separators.  For  constrained  types,  the  number  of  bytes  occupied  by  each 
element  is  the  size  of  the  constrained  type  and  is  the  same  for  all  elements. 

Files  created  using  SEQUENTIAL.IO  on  constrained  types  can  be  accessed  as 
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Elements  within  a  DIRECT.IO  file  always  have  the  same  size.  This  requirement 
allows  the  Ada  runtime  to  easily  and  quickly  compute  the  location  of  any 
element  in  a  DIRECT.IO  file. 

For  a  DIRECT.IO  file  instantiated  with  a  constrained  type,  the  number  of  bytes 
occupied  by  each  element  is  the  size  of  the  constrained  type.  Files  created 
using  DIRECT.IO  on  constrained  types  can  be  accessed  as  SEQUENTIAL.IO  files 
at  a  later  time.  The  representation  of  both  DIRECT.IO  and  SEQUENTIAL.IO  files 
are  the  same  when  using  a  constrained  type. 

For  DIRECT.IO  files  instantiated  with  an  unconstrained  type,  the  number 
of  bytes  occupied  by  each  element  is  determined  by  the  FORM  parameter, 
RECORD. SIZE.  All  of  the  unconstrained  objects  stored  in  the  file  must  have  an 
actual  size  that  is  less  than  or  equal  to  this  size.  The  exception  DATA.ERROR 
is  raised  if  the  size  of  an  unconstrained  object  is  larger  than  this  size.  Files 
created  using  DIRECT.IO  on  unconstrained  types  cannot  be  accessed  as 
SEQUENTIAL.IO  files  at  a  later  time.  The  representation  of  DIRECT.IO  and 
SEQUENTIAL.IO  files  are  not  the  same  when  using  an  unconstrained  type.  See 
section  “F  8.2.10.2  The  Structure  of  DIRECT.IO  and  SEQUENTIAL.IO 
Files”  for  more  information  on  file  structure. 

If  the  file  is  created  with  the  default  FORM  parameter  attributes  (see  section 
“F  8.2  The  FORM  Parameter”),  only  objects  of  a  constrained  type  can 
be  written  to  or  read  from  a  DIRECT.IO  file.  Although  an  instantiation  of 
DIRECT.IO  is  accepted  for  unconstrained  types,  the  exception  USE.ERROR 
is  raised  on  any  call  to  CREATE  or  OPEN  when  the  default  value  of  the  FORM 
parameter  is  used.  You  must  specify  the  maximum  RECORD. SIZE  for  the 
unconstrained  type. 

A  DIRECT.IO  file  can  be  buffered.  Buffering  is  selected  by  specifying  a  non-zero 
value  for  the  FORM  parameter.  BUFFER.SIZE.  The  I/O  performance  of  an  Ada 
program  will  normally  be  considerably  improved  if  buffering  is  used.  However, 
for  a  DIRECT.IO  file  that  is  accessed  in  a  random  fashion,  performance  can 
actually  be  degraded.  The  buffer  will  always  reflect  a  contiguous  set  of 
elements  in  the  file  and  if  subsequent  I/O  requests  lie  outside  of  the  current 
buffer,  the  entire  buffer  will  be  updated.  This  could  cause  performance 
to  degrade  if  a  large  buffer  is  used  and  each  I/O  request  requires  that  the 
buffer  be  updated.  By  default,  no  buffering  takes  place  between  the  physical 
external  file  and  the  Ada  program.  See  section  “F  8.2.4  The  FOR.M  Parameter 
.Attribute  -  File  Buffering"  for  details  on  specifying  a  file  BUFFER.SIZE. 
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A  TEXT.IO  file  can  be  buffered.  Buffering  is  selected  by  specifying  a  non-zero 
value  for  the  FORM  parameter,  BUFFER.SIZE.  The  I/O  performance  of  an  Ada 
program  will  be  considerably  improved  if  buffering  is  used.  By  default,  no 
buffering  takes  place  between  the  physical  external  file  and  the  Ada  program. 
However,  terminal  input  is  line  buffered  by  default.  See  sections  “F  8.2.4 
The  FORM  Parameter  Attribute  -  File  Buffering”  and  “F  8.2.8  The  FORM 
Parameter  -  FIFO  Control”  for  details. 


F  8.1.4  Default  Access  Protection  of  External  Files 

HP-UX  provides  protection  of  a  file  by  means  of  access  rights.  These  access 
rights  are  used  within  Ada  programs  to  protect  external  files.  There  are  three 
levels  of  protection: 

■  User  (the  owner  of  the  file). 

■  Group  (users  belonging  to  the  owner’s  group). 

■  Others  (users  belonging  to  other  groups). 

For  each  of  these  levels,  access  to  the  file  can  be  limited  to  one  or  several  of 
the  following  rights:  read,  write,  or  execute.  The  default  HP-UX  external  file 
access  rights  are  specified  by  using  the  umaskCl)  command  (see  umaskd)  and 
uinask(2)  in  the  HP-UX  Reference.)  Access  rights  apply  equally  to  sequential, 
direct,  and  text  files.  See  section  “F  8.2.3  The  FORM  Parameter  Attribute  - 
File  Protection”  for  information  about  specifying  file  permissions  at  the  time  of 
CREATE. 


F  8.1.5  System  Level  Sharing  of  External  Files 

Under  HP-UX,  several  programs  or  processes  can  access  the  same  HP-UX  file 
simultaneously.  Each  program  or  process  can  access  the  HP-UX  file  either  for 
reading  or  for  writing.  Although  HP-UX  can  provide  file  and  record  locking 
protection  using  fcntl(2)  or  lockf  (2),  .4da  does  noi  utilize  this  feature 
when  it  performs  I/O  on  external  files.  Thus,  the  external  file  that  Ada  reads 
or  writes  is  not  protected  from  simultaneous  access  by  non-Ada  processes,  or 
by  another  Ada  program  that  is  e.xecuting  concurrently.  Such  protection  is 
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F  8.1.6  I/O  Involving  Access  Types 

When  an  object  of  an  access  type  is  specified  as  the  source  or  destination  of  an 
I/O  operation  (read  or  write),  the  32-bit  binary  access  value  is  read  or  written 
unchanged.  If  an  access  value  is  read  from  a  file,  make  sure  that  the  access 
value  read  designates  a  valid  object.  This  will  only  be  the  case  if  the  access 
value  read  was  previously  written  by  the  same  execution  of  the  program  that  is 
reading  it,  and  the  object  which  it  designated  at  the  time  it  was  written  still 
exists  (that  is,  the  scope  in  w-hich  it  was  allocated  has  not  been  exited,  nor  has 
an  UWCHECKED.DEALLOCATION  been  performed  on  it).  A  program  may  execute 
erroneously  or  raise  PROGRAM.ERROR  if  an  access  type  read  from  a  file  does  not 
designate  a  valid  object.  In  general,  I/O  involving  access  types  is  strongly 
discouraged. 


F  8.1.7  I/O  Involving  Local  Area  Networks 

This  section  assumes  knowledge  of  networks.  It  describes  .4da  program  I/O 
involving  Local  Area  Network  (LAN)  services  available  on  the  Series  600,  700, 
and  800  computers. 

The  .4da  programs  discussed  here  are  executed  on  a  local  (host)  computer. 
These  programs  access  or  create  files  on  a  remote  system,  which  is  connected  to 
a  mass  storage  device  not  directly  connected  to  the  host  computer.  The  remote 
file  system  can  be  mounted  and  accessed  by  the  host  computer  using  NFSj 
LAN  services.  NFS  systems  are  described  in  the  manuals  Using  ^^FS  Services 
and  Installing  and  Administering  NFS  Services. 

t  NFS  is  a  trademark  of  Sun  Microsystems,  Inc. 
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Note  that  the  file  protection  provided  by  the  Ada  runtime  is  not  the  same 
as  the  protection  provided  by  the  use  of  the  SHARED  attribute  of  the  FORM 
parameter  of  CREATE  or  OPEN  calls.  The  FORM  parameter  either  prohibits  or 
allows  multiple  Ada  file  objects  to  share  the  same  external  file.  In  contrast,  the 
file  protection  provided  by  the  Ada  runtime  prohibits  the  simultaneous  sharing 
of  the  same  Ada  file  object  between  tasks.  The  SHARED  attribute  always  deals 
with  multiple  Ada  file  objects. 

The  file  protection  provided  by  the  Ada  runtime  will  only  be  a  problem  when 
the  same  Ada  file  object  is  used  by  different  tasks.  When  each  task  uses  a 
separate  file  object,  it  is  not  necessary  to  provide  explicit  synchronization  when 
performing  I/O  operations.  This  is  true  even  when  the  file  objects  are  sharing 
the  same  external  file.  However,  for  this  case,  you  will  need  to  consider  the 
effects  of  the  SHARED  attribute  and/or  file  buffering. 


Caution  It  is  your  responsibility  to  utilize  proper  synchronization  and 
mutual  exclusion  in  the  use  of  shared  resources.  Note  that 
shared  access  to  a  common  resource  (in  this  case,  a  file  object) 
could  be  achieved  by  a  rendezvous  between  tasks  that  share 
that  resource.  If  you  write  a  program  in  which  two  tasks 
attempt  to  perform  I/O  operations  on  the  same  logical  file 
without  proper  synchronization,  that  program  is  erroneous. 
(See  Ada  RM,  section  9.11  ) 


F  8.1.9  I/O  Involving  Symbolic  Links 

Some  caution  must  be  exercised  when  using  an  Ada  program  that  performs  I/O 
operations  to  files  that  involve  symbolic  links.  For  more  detail  on  the  use  of 
symbolic  links  to  files  in  HP-UX,  see  ln(l). 

Creating  a  symbolic  link  to  a  file  creates  a  new  name  for  that  file;  that  is,  an 
alias  for  the  actual  file  name  is  created.  If  you  use  the  actual  file  name  or  its 
alias  (that  is,  the  name  involving  symbolic  links),  Ada  I/O  operations  will  work 
correctly.  However,  the  NAME  function  in  the  TEXT.IO,  SEQUENTIAL.IO,  and 
DIRECT.IO  packages  will  always  return  the  actual  ro.oted  path  of  a  file  and  not 
a  path  involving  symbolic  links. 
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runtime  is  in  the  process  of  determining  the  name  of  a  file,  the 
Ada  runtime  may  be  unable  to  restore  the  current  working 
directory.  This  can  only  occur  if  the  permission  change  denies 
the  effective  user  of  the  Ada  program  read  (r)  or  search  (x) 
access  to  the  directory  whose  permission  changed.  Because  it  is 
unsafe  for  the  program  to  continue  execution  with  an  incorrect 
current  working  directory,  the  Ada  runtime  will  abort  the  Ada 
program  with  a  diagnostic  message  to  stderr  and  a  non-zero 
exit  status.  This  abnormal  termination  can  only  occur  if; 

1.  The  permissions  for  a  directory  (such  as  /A)  in  the  rooted 
path  to  a  directory  (such  as  /A/B/C)  are  changed  while  an 
Ada  program  is  running  with  /A/B/C  as  its  current  working 
directory. 

2.  The  effective  user  of  the  Ada  program  loses  read  (r)  or 
search  (x)  permission  (such  as  /A)  because  of  the  change. 

3.  The  Ada  runtime  was  in  the  process  of  determining  the 
name  of  a  file  when  the  permission  changed. 


For  example,  when  opening  a  file,  the  Ada  exception  NAME.ERROR  is  raised  if 
there  are  any  directories  in  the  rooted  path  of  the  file  that  are  not  readable  or 
searchable  by  the  ‘‘effective  uid”  of  the  program.  This  restriction  applies  to 
intermediate  path  components  that  are  encountered  during  the  resolution  of 
symbolic  links. 

Also,  if  access  to  an  NFS  “hard”  mounted  remote  file  system  is  lost  (possibly 
due  to  a  network  failure),  subsequent  OPEN  or  CREATE  calls  on  a  file  whose 
actual  rooted  path  contains  the  parent  directory  of  the  NFS  mount  point  might 
not  complete  until  the  NFS  failure  is  corrected  (whether  or  not  the  actual  file 
being  accessed  is  on  the  failed  NFS  volume.) 
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The  general  format  for  the  FORM  parameter  is  a  string  formed  from  a  list  of 
attributes  with  attributes  separated  by  commas.  (FORM  attributes  are  distinct 
from  Ada  attributes  and  the  two  are  not  related.)  The  FORM  parameter  string 
is  not  case  sensitive.  The  arrow  symbol  can  be  separated  by  spaces  from  the 
keyword  and  qualifier.  The  two  forms  below  are  equivalent: 

KEYWORD  *>  QUALIFIER 
KEYWORD  QUALIFIER 

In  some  cases,  an  attribute  can  have  multiple  qualifiers  that  can  be  presented 
at  the  same  time.  In  cases  that  allow  multiple  qualifiers,  additional  qualifiers 
are  introduced  with  an  underscore  (_).  Note  that  spaces  are  not  allowed 
between  the  additional  qualifiers;  only  underscore  characters  are  allowed. 
Otherwise,  a  USE.ERROR  exception  is  rziised  by  CREATE.  The  two  examples  that 
follow  illustrate  the  FORM  parameter  format. 

The  first  example  illustrates  the  use  of  the  FORM  parameter  in  the 
TEXT.IO.OPEN  to  set  the  file  buffer  size. 


—  Example  of  opening  a  file  using  the  non-generic 
--  package  TEXT.IO.  This  illustrates  the  use  of  the 

—  FORM  parameter  BUFFER.SIZE. 

--  Note:  "input. file"  must  exist  or  NAME.ERROR  will  be 

—  raised, 
with  TEXT.IO; 
procedure  STEST  is 

— Define  a  file  object  for  use  in  Ada 
TFILE  :  TEXT.IO. FILE.TYPE; 
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F  8.2.3  The  FORM  Parameter  Attribute  -  File  Protection 

The  file  protection  attribute  is  only  meaningful  for  a  call  to  the  CREATE 
procedure. 

File  protection  involves  two  independent  classifications.  The  first  classification 
specifies  which  user  can  access  the  file  and  is  indicated  by  the  keywords  listed 
in  Table  8-2. 

Table  8-2.  User  Access  Categories 


Category 

Grants  Access  To 

OWNER 

Only  the  owner  of  the  created  file. 

GROUP 

Only  the  members  of  a  defined  group. 

WORLD 

Any  other  users 

Note  that  WORLD  is  similar  to  “others”  in  HP-UX  terminology,  but  was  used  in 
its  place  because  OTHERS  is  an  Ada  reserved  word. 

The  second  classification  specifies  access  rights  for  each  classification  of 
user.  The  four  general  types  of  access  rights,  which  are  specified  in  the  FORM 
parameter  qualifier  string,  are  listed  in  Table  8-3. 


Table  8'3.  File  Access  Rights 


Category 

Allows  the  User  To 

READ 

Read  from  the  external  file. 

WRITE 

Write  to  the  external  file. 

EXECUTE 

Execute  a  program  stored  in  the  external  file. 

NONE 

The  user  has  no  access  rights  to  the  external  file.  (This  qualifier 
overrides  any  prior  privileges). 
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F  8.2.4  The  FORM  Parameter  Attribute  >  File  Buffering 

The  buffer  size  can  be  specified  by  the  attribute: 

BUFFER.SIZE  =>  size  ^in-bytes 

The  default  value  for  BUFFER.SIZE  is  2048  bytes.  A  value  of  zero  specifies  no 
buffering.  Note  that  a  BUFFER.SIZE  value  of  one  also  specifies  no  buffering 
and  is  treated  identical  to  the  value  zero.  Using  the  file  buffering  attribute 
will  improve  I/O  performance  by  a  considerable  amount  in  most  cases.  If  I/O 
performance  is  a  concern  for  disk  files,  the  attribute  BUFFER.SIZE  should  be  set 
to  a  value  that  is  an  integral  multiple  of  the  size  of  a  physical  disk  block.  The 
size  of  a  physical  disk  block  can  be  found  in  <sys/parain.h>  and  is  1024  bytes 
for  the  HP  9000  Series  600,  700,  and  800. 

An  example  of  using  the  FORM  parameter  in  the  TEXT.IO.OPEN  to  set  the  file 
buffer  size  is  shown  below: 

—  An  example  of  creating  a  file  using  the  non-generic 

—  package  TEXT.IO.  This  illustrates  the  use  of  the 

—  FORM  parameter  BUFFER.SIZE. 

with  TEXT.IO; 
procedure  T.TEST  is 

BFILE  :  TEXT_I0.FILE.TYPE;  —  Define  a  file  object 

—  for  use  by  Ada 


begih  —  T.TEST 


TEXT. 10. CREATE  (FILE  *>  BFILE, 

—  Ada  file  is  BFILE 
MODE  =>  TEXT.IO. OUT.FILE, 

—  MODE  is  WRITE  only 
NAME  *>  "txt.file", 

—  External  file  "txt.file" 
FORM  *>  "BUFFER.SIZE  =>  8192" 


): 


Buffer  size  is  8192  bytes 


end  T.TEST; 
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F  8.2.5  The  FORM  Parameter  Attribute  •  File  Sharing 

The  file  sharing  attribute  of  the  FORM  parameter  allows  you  to  specify  what 
kind  of  sharing  is  permitted  when  multiple  file  objects  access  the  same  external 
file.  This  control  over  file  sharing  is  not  system-wide,  but  is  limited  to  a 
single  Ada  program.  The  HP-UX  operating  system  controls  file  sharing  at  the 
system  level.  See  section  “F  8.1.5  System  Level  Sharing  of  External  Files”  for 
information  on  system  level  file  sharing  between  separate  programs. 

An  external  file  can  be  shared;  that  is,  the  external  file  can  be  associated 
simultaneously  with  several  logical  file  objects  created  by  the  OPEN  or  CREATE 
procedures.  The  file  sharing  attributes  forbids  or  limits  this  capability  by 
specifying  one  of  the  modes  listed  in  Table  8-4. 


Table  8-4.  File  Sharing  Attribute  Modes 


Mode 

Description 

BOT.SHARED 

Indicates  exclusive  access.  No  other  logical  file  can 
be  associated  with  the  external  file. 

SHARED=>  READERS 

Only  logical  files  of  mode  IN  can  be  associated  with 
the  external  file. 

SHARED*>  SIHGLE.URITER 

Only  logical  files  of  mode  IN  and  at  most  one  file 
with  mode  OUT  can  be  associated  with  the  external 
file. 

SHARED=>  ANY 

No  restrictions;  this  is  the  default. 
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Due  to  this  behavior,  shared  files  should  not  be  buffered  if  any  write  operations 
are  to  be  performed  on  this  file.  This  would  be  the  case  for  file  objects  of  the 
mode  OUT.FILE  or  INOUT.FILE.  Thus,  when  using  buffered  files  safely,  no 
writers  are  allowed,  but  multiple  readers  are  allowed. 

File  buffering  is  enabled  by  using  the  FORM  parameter  attributes  at  the  time 
you  open  or  create  the  file.  If  file  buffering  is  enabled  for  a  file,  you  should  also 
specify  a  file  sharing  attribute  of  either  NOT_SHARED  or  SHARED=>READERS  to 
prevent  the  effects  of  file  buffering  and  file  sharing  interfering  with  one  another. 
The  Ada  runtime  will  raise  the  exception  USE.ERROR  if  any  attempt  is  made 
to  share  the  file  or  to  share  and  write  the  file,  when  the  above  file  sharing 
attributes  are  provided  as  FORM  parameters. 

If  the  possibility  of  shared  access  exists  in  your  Ada  program  for  sequential 
devices  or  interactive  devices,  you  should  specify  a  file  sharing  attribute  of 
NOT.SHARED.  This  will  prevent  the  negative  effects  of  file  sharing  on  these  kinds 
of  devices. 


F  8.2.6  The  FORM  Parameter  Attribute  •  Appending  to  a  File 

The  APPEND  attribute  can  only  be  used  with  the  procedure  OPEN.  Its  format  is: 
APPEND 

Any  output  will  be  placed  at  the  end  of  the  named  external  file. 

Under  normal  circumstances,  when  an  external  file  is  opened,  an  index  is  set 
that  points  to  the  beginning  of  the  file.  If  the  APPEND  attribute  is  present  for  a 
sequential  or  text  file,  data  transfer  begins  at  the  end  of  the  file.  For  a  direct 
access  file,  the  value  of  the  index  is  set  to  one  more  than  the  number  of  records 
in  the  external  file. 

The  APPEND  attribute  is  not  applicable  to  terminal  devices. 
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Caution  If  a  “blocked”  I/O  operation  is  frequently  interrupted 
and  restarted  as  described  above,  the  operation  may  be 
unable  to  complete  successfully.  In  addition,  under  some 
circumstances,  data  could  be  lost  by  HP-UX  when  an  I/O 
operation  is  interrupted  and  restarted.  To  avoid  these 
difficulties,  either  specify  (or  default)  the  FORM  parameter 
to  NON.BLOCKING  or,  if  a  “true  blocking”  I/O  operation  is 
needed,  specify  (or  default)  the  FORM  parameter  to  BLOCK 
and  additionally  surround  the  “blocking”  I/O  operation 
with  calls  to  SYSTEM.ENVIRONMENT .  SUSPEND. ADA.TASKING 
and  SYSTEM.ENVIRONMENT. RESUME. ADA.TASKING.  The 
SYSTEM.ENVIRONMENT. SUSPEND. ADA.TASKING  call  will  disable 
or  block  the  HP-UX  signals  associated  with  delay,  time-slicing, 
and  interrupt  handlers  or  entries  during  the  I/O  operation. 
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F  B.2.8  The  FORM  Parameter  -  FIFO  Control 

The  FIFO  control  attribute  has  one  of  two  alternate  forms; 

FIFO.EOF  =>  YES 

FIFD.EOF  =>  NO 

The  default  value  of  FIFO.EOF  is  YES. 

The  FIFO.EOF  attribute  controls  the  behavior  of  an  Ada  file  associated  with  a 

FIFO  special  file,  as  follows: 

■  When  a  FIFO  special  file  is  opened  for  reading  (IN.FILE),  by  default 
(FIFO.EOF  ->  YES)  the  Ada  END.OF.FILE  condition  becomes  true  when  the 
last  process  having  the  FIFO  open  for  writing  closes  the  FIFO  special  file. 

■  When  a  FIFO  special  file  is  opened  for  reading  (IN.FILE)  and 
FIFO.EOF  =>  NO  is  specified,  the  Ada  END.OF.FILE  condition  never  becomes 
true  and  so  another  mechanism  is  needed  to  signal  that  no  further  attempts 
to  read  from  such  a  FIFO  should  be  attempted.  This  mode  of  operation 
would  most  likely  be  used  by  a  monitor  or  daemon  type  program  that 
monitors  (reads)  a  FIFO  that  does  not  always  have  a  writing  process 
attached  to  it.  This  mode  of  operation  may  also  be  necessary  when  a  FIFO 
special  file  is  opened  for  reading,  in  NON.BLOCKING  mode,  to  avoid  premature 
signaling  of  the  Ada  END.OF.FILE  condition  when  there  are  currently  no 
processes  with  the  FIFO  open  for  writing. 

■  When  a  FIFO  special  file  is  opened  for  writing  (OUT.FILE),  by  default 
(FIFO.EOF  =>  YES).  There  are  no  special  conditions  or  behaviors  if  the  FIFO 
is  opened  in  BLOCKING  mode  (the  default  in  non-tasking  programs).  If  the 
FIFO  is  opened  in  NON.BLOCKING  mode  (the  default  in  tasking  programs), 
the  open  will  fail  with  a  USE.ERROR  if  the  FIFO  is  not  already  open  for 
reading  by  another  (or  the  same)  process. 
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F  8.2.9  The  FORM  Parameter  -  Terminal  input 

The  terminal  input  attribute  has  one  of  two  alternative  forms: 

TERMINAL.INPUT  =>  LINES, 

TERMINAL.INPUT  =>  CHARACTERS. 

Terminal  input  is  normally  processed  by  Ada  (and  HP-UX)  in  units  of  one 
line  at  a  time.  An  Ada  program  attempting  to  read  from  the  terminal  as  an 
external  file  does  not  receive  any  data  from  the  terminal  until  a  complete  line  is 
typed.  At  that  time,  the  outstanding  read  operation  (and  possibly  subsequent 
read  operations)  is  satisfied.  In  this  mode,  the  HP-UX  line  editing  characters 
“kill’’  and  "erase”  can  be  used  to  edit  the  input  characters  before  the  Ada 
program  is  given  access  to  the  characters. 

The  TERMINAL.INPUT  =>  LINES  attribute,  the  default  case,  specifies  the  one  line 
at  a  time  mode  of  transfer.  Note  that  the  BUFFER.SIZE  attribute  may  be  set 
to  an\-  value  greater  or  equal  to  zero  when  LINES  mode  is  in  effect.  However, 
if  the  BUFFER.SIZE  is  greater  than  one,  no  characters  are  available  to  the  Ada 
program  until  at  least  BUFFER.SIZE  of  them  have  been  entered  (which  may 
require  multiple  lines  of  input).  Once  BUFFER.SIZE  number  of  characters  has 
been  entered,  only  BUFFER.SIZE  number  of  characters  are  available  to  the 
Ada  program  until  the  next  BUFFER.SIZE  number  of  characters  are  entered. 
Because  BUFFER.SIZE  number  of  characters  may  be  reached  in  the  middle  of  a 
line,  the  behavior  of  the  program  may  be  confusing  to  the  person  entering  data. 
A  BUFFER.SIZE  greater  than  one  is  not  recommended  if  a  person  is  entering 
data,  although  it  may  make  sense  if  the  “terminal’"  is  a  data  communication 
line  from  a  device  that  is  producing  the  data.  Refer  to  the  section  on  “Ada 
I/O  Operations  on  a  Terminal  or  Pipe/FIFO”  in  Chapter  7  in  the  Ada  User's 
Guide  for  additional  information. 

Terminal  input  can  optionally  be  processed  by  Ada  (and  HP-UX)  in  units 
of  one  character  at  a  time.  An  Ada  program  attempting  to  read  from  the 
terminal  as  an  external  file  will  receive  data  from  the  terminal  as  it  is  typed. 

In  this  mode,  the  HP-UX  line  editing  characters  “kill”  and  “erase”  may  not  be 
used  to  edit  the  input  characters  before  the  .4da  program  is  given  access  to  the 
characters. 
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F  8.2.10  The  FORM  Parameter  Attribute  •  File  Structuring 

This  section  describes  the  structure  of  Ada  files.  It  also  describes  how  to  use 
the  FORM  parameter  to  effect  the  structure  of  Ada  files. 


F  8.2.10.1  The  Structure  of  TEXT.IO  Files 

There  is  no  FORM  parameter  to  define  the  structure  of  text  files.  A  text  file 
consists  of  a  sequence  of  bytes  containing  ASCII  character  codes. 

The  usage  of  Ada  terminators  depends  on  the  file's  mode  (IN.FILE 
or  OUT.FILE)  and  whether  it  is  associated  with  a  terminal  device  or  a 
mass-storage  file. 
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F  8.2.10.2  The  Structure  of  DIRECT.IO  and  SEQUENTIAL.IO  FUes 

This  section  describes  use  of  the  FORM  parameter  for  binary  (sequential  or 
direct  access)  files.  Two  FORM  attributes,  RECORD.SIZE  and  RECORD  .UNIT, 
control  the  structure  of  binary  files. 

Such  a  file  can  be  viewed  as  a  sequence  or  a  set  of  consecutive  RECORDS.  The 
structure  of  a  record  is 

[  HEADER  ]  OBJECT  [  UNUSED.PART  ] 

A  record  is  composed  of  up  to  three  items: 

1.  A  HEADER  consisting  of  two  fields  (each  32  bits): 

■  The  length  of  the  object  in  bytes. 

■  The  length  of  the  descriptor  in  bytes;  for  this  implementation  of  Ada.  the 
length  is  always  zero. 

2.  An  OBJECT  with  the  exact  binary  representation  of  the  Ada  object  in  the 
executable  program,  possibly  including  an  object  descriptor. 

3.  An  UNUSED.PART  of  variable  size  to  permit  full  control  of  the  record’s  size. 

The  HEADER  is  implemented  only  if  the  actual  parameter  of  the  instantiation  of 
the  I/O  package  is  unconstrained. 

The  file  structure  attributes  take  the  form: 

RECORD.SIZE  «>  sizc-in^bytes 

RECORD.UNIT  «>  size^in^bytes 

.The  attributes’  meaning  depends  on  the  object’s  type  (constrained  or 
unconstrained)  and  the  file  access  mode  (sequential  or  direct  access). 
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Table  8*6. 

Structuring  Binary  Files  with  the  FORM  Parameter  (Continued) 


Object  Type 

File  Access 
Mode 

RECORD-UNIT 

Attribute 

RECORD-SIZE 

Attribute 

Unconstrained 

Sequential  I/O 

By  default,  the 
RECORD-UBIT  attribute 
is  one  byte. 

The  size  of  the  record  is 
the  smallest  multiple  of 
the  specified  (or  default) 
RECORD-UBIT  that  holds 
the  object  and  its  eight 
byte  HEADER  (which  is 
always  present  in  this 
case).  This  is  the  only 
case  where  different 
records  in  a  file  can  have 
different  sizes 

The  RECORD.SIZE 
attribute  is  illegal. 

Continued  on  the  next  page. 
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F  9.  The  Ada  Development  System  and 
HP-UX  Signals 


The  Ada  runtime  on  the  HP  9000  Series  600/700/800  uses  HP-UX  signals  to 
implement  the  following  features  of  the  Ada  language: 

■  Ada  exception  handling. 

■  Ada  task  management. 

■  Ada  delay  timing. 

■  .^da  program  termination. 

■  Ada  interrupt  entries. 
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Note 


The  signals  SIGSEGV,  SIGBUS,  and  SIGILL  are  not  reserved 
by  the  Ada  runtime.  These  signals  are  never  deliberately 
produced  by  generated  code  or  by  the  Ada  runtime  to  cause 
an  exception  to  be  raised.  If,  due  to  a  programming  error, 
access  is  attempted  on  misaligned  or  protected  data  (causing 
SIGSEGV  or  SIGBUS)  or  an  illegal  instruction  is  executed 
(causing  SIGILL),  a  PROGRAH.ERROR  occurs.  When  receiving 
these  signals,  a  PROGRAH.ERROR  is  raised  unless  the  application 
has  overridden  the  Ada  runtime  and  an  alternative  action 
has  been  specified.  If  the  Interrupt  Entry  mechanism  (see 
Chapter  12)  is  used  to  specify  an  .4.da  handler  for  one  or  more 
of  these  signals,  and  the  ORIGINAL.HANDLER  parameter  to 
INSTALL.HANDLER  was  not  REPLACED,  the  “original  handler” 
that  will  be  invoked  (either  FIRST  or  LAST)  will  be  the  default 
Ada  runtime  handler  that  will  raise  PROGRAH.ERROR.  Therefore, 
ORIGINAL.HANDLER  *>  REPLACED  is  recommended  when  using 
INSTALL.HANDLER  with  one  of  these  signals. 
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If  the  Ada  program  contains  tasks,  the  following  is  true: 


If  the  Ada  program  contains 

no  delay  statements 

one  or  more  delay 
statements 

If  time-slicing 
is  disabled  with 

-Wb.-s.O 

SIGALRH  noi  reserved 

SIGVTALRM  not  reserved 

SIGPROF  noi  reserved 

SIGALRH  reserved 

SIGVTAUIH  not  reserved 

SIGPROF  noi  reserved 

If  time-slicing 
is  enabled  with 

SIGALRH  timer 
with  -W  b ,  -S ,  a 

SIGALRH  reserved 

SIGVTALRM  not  reserved 

SIGPROF  noi  reserved 

SIGALRH  reserved 

SIGVTALRM  not  reserved 

SIGPROF  noi  reserved 

If  time-slicing 
is  enabled  with 

SIGVTALRM  timer 
with  -W  b,-S,v 

SIGALRH  not  reserved 

SIGVTALRM  reserved 

SIGPROF  noi  reserved 

SIGALRH  reserved 

SIGVTALRM  reserved 

SIGPROF  not  reserved 

If  time-slicing 
is  enabled  with 

SIGPROF  timer 
with  -W  b,-S,p 

SIGALRH  not  reserved 

SIGVTALRM  not  reserved 

SIGPROF  reserved 

SIGALRH  reserved 

SIGVTALRM  not  reserved 

SIGPROF  reserved 

If  a  timer  signal  is  not  reserved  in  an  application  program  configuration  shown 
above,  the  signal  can  be  used  for  any  application-defined  purpose,  including 
being  associated  with  an  interrupt  entry  (see  “F  9.7  HP-UX  Signals  Used  for 
Ada  Interrupt  Entries"  and  section  ‘T  12.  Interrupt  Entries”  for  details.) 
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F  9.3  HP-UX  Signals  Used  for  Ada  Exception  Handling 

The  Ada  implementation  uses  signals  to  raise  exceptions.  The  Ada  runtime 
handlers  for  these  signals  are  set  during  the  elaboration  of  the  Ada  runtime 
system.  Defining  a  new  handler  for  any  of  these  signals  subverts  the  normal 
exception  handling  mechanism  of  Ada  and  will  most  likely  result  in  an 
erroneous  runtime  execution. 

If  your  Ada  program  uses  external  interfaced  subprograuns,  you  must  ensure 
that  these  external  interfaced  subprograms  do  not  redefine  the  signal  behavior 
for  any  of  the  HP-UX  signals  reserved  by  the  Ada  runtime.  If  you  change  the 
signal  behavior  for  the  signal  used  for  Ada  exception  handling  (SIGFPE)  and 
your  Ada  program  attempts  to  raise  an  exception,  unpredictable  program 
behavior  will  result. 

Tlie  SIGFPE  signal  has  a  predefined  meaning  and  is  reserved  for  use  by  the 
Ada  runtime  for  exception  handling.  The  SIGFPE  signal  is  generated  in 
your  compiled  Ada  code  whenever  one  of  the  predefined  runtime  checks  fail, 
including  null  access  value  checks.  The  runtime  examines  the  context  in  which 
the  signal  occurred  and  raises  the  appropriate  exception:  CONSTRAINT.ERROR, 
NUMERIC.ERROR.STORAGE.ERROR,  or  PROGRAM.ERROR.  An  unexpected  SIGFPE 
signal  that  was  generated  outside  of  Ada  code  or  sent  to  the  process  from 
an  outside  source  causes  the  exception  PROGRAM.ERROR  to  be  raised.  If 
the  unexpected  signal  occurred  in  a  context  where  the  runtime  believed  a 
legitimate  exception  could  have  occurred,  that  exception  is  raised  instead  of 
PROGRAM.ERROR. 
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Note 


The  Ada  binder  does  not  specify  -z  or  -Z  to  the  linker  (ld(l)) 
to  control  the  system  action  on  a  dereference  of  a  null  pointer. 
Either  the  ld(l)  default  or  a  user-specified  value  (using  -W  1) 
will  therefore  take  effect. 

If  Ada  code  is  compiled  with  checks  enabled  (the  default  case), 
the  Ada  Runtime  System  will  operate  properly  with  either  -z 
or  -Z  linker  options.  This  is  because  Ada  generates  software 
checks  for  null  pointer  dereferencing. 

If  Ada  code  is  compiled  with  pointer  dereference  checks 
disabled  (using  the  -C  or  -R  compiler  options  or  using  pragma 
SUPPRESS),  some  null  pointer  checking  can  be  restored  with  no 
runtime  overhead  by  using  the  -z  linker  option. 

If  -z  is  specified,  the  system  will  send  SIGSEGV  when  a  null 
pointer  is  dereferenced;  the  Ada  Runtime  System  will  map  that 
signal  to  PROGRAM.ERROR.  The  Ada  software  checks  for  nidi 
pointer  dereferencing  are  intended  to  handle  all  cases  where  a 
null  pointer  could  appear.  CONSTRAINT.ERROR  will  be  raised  if 
such  a  dereference  occurs.  SIGSEGV,  enabled  by  the  -z  linker 
option,  will  only  be  sent  when  the  final  result  of  an  address 
calculation  is  the  null  pointer.  The  resulting  exception  will  be 
PROGRAM.ERROR  instead  of  CONSTRAINT.ERROR. 
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F  9.5  HP-UX  Signals  Used  for  Ada  Delay  Timing 

When  an  Ada  program  contains  delay  statements,  the  Ada  runtime  system 
uses  SIGALRM  to  time  the  delay  intervals.  The  resolution  of  the  SIGALRM  timer 
is  1/100  of  a  second.  Thus,  all  delay  statements  are  implemented  using  actual 
delays  that  are  integral  multiples  of  1/100  of  a  second.  Non-zero  delays  for 
periods  smaller  than  1/100  of  a  second  will  delay  for  at  least  1/100  of  a  second. 
Zero  delays  will  not  cause  an  actual  delay,  but  will  provide  an  opportunity  for 
the  Ada  runtime  to  change  the  currently  running  task  to  a  different  task  (if 
appropriate). 

If  an  Ada  program  contains  delay  statements,  SIGALRM  is  reserved.  If  an  Ada 
program  contains  tasks  but  does  not  contain  any  delay  statements,  SIGALRM 
may  or  may  not  be  reserved  (see  “F  9.1  HP-UX  Signals  Reserved  by  the  Ada 
Runtime”  for  details). 

If  your  Ada  program  uses  external  interfaced  subprograms,  you  must  ensure 
that  these  external  interfaced  subprograms  do  not  redefine  the  signal  behavior 
for  any  of  the  HP-UX  signals  reserved  by  the  Ada  runtime.  If  you  change  the 
signal  behavior  used  for  Ada  delay  timing  (SIGALRM)  and  your  Ada  program 
contains  a  delay  statement,  unpredictable  program  behavior  will  result. 
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Caution 


If  a  signal  is  not  currently  reserved  by  the  Ada  runtime  (see  the 
appropriate  sections  of  F  9)  or  is  not  recognized  as  an  attempt 
to  terminate  the  Ada  program  (see  the  list  of  such  signals 
above)  and  is  received  by  the  Ada  program,  the  HP-UX  action 
may  be  to  terminate  the  program.  Such  a  termination  will 
not  be  intercepted  by  the  Ada  runtime  and  the  Ada  runtime 
cleanup  actions  will  not  occur.  This  could  cause  corrupted  files 
and/or  corrupted  terminal  states.  If  an  Ada  program  is  likely 
to  receive  such  signals,  the  program  should  arrange  to  ignore  or 
mask  such  signals  or  to  catch  and  handle  such  signals.  If  such  a 
signal  terminates  the  Ada  program,  the  Ada  program  should 
arrange  to  catch  and  handle  such  a  signal,  and  should  then 
send  one  of  the  defined  termination  signals  (see  list  above)  to 
itself  to  trigger  the  Ada  signaled  termination  process.  The  Ada 
program  should  ensure  that  the  original  Ada  handler  is  in  effect 
for  that  termination  signal  and  that  the  signal  is  not  masked 
before  sending  the  signal  to  itself. 
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F  9.8  Protecting  Interfaced  Code  from  Ada’s 
Asynchronous  Signals 

The  SIGALRH,  SIGVTALRM,  and  SIGPROF  signals  (described  in  sections  “F  9.4 
HP-UX  Signals  Used  for  Ada  Task  Management”  and  “F  9.5  HP-UX  Signals 
Used  for  Ada  Delay  Timing”)  occur  aisynchronously.  Because  of  this,  they  may 
occur  while  your  code  is  executing  an  external  interfaced  subprogram.  For 
details  on  protecting  your  external  interfaced  subprogram  from  adverse  effects 
caused  by  these  signals,  see  the  section  in  the  Ada  User’s  Guide  on  “Interfaced 
Subprograms  and  Ada’s  Use  of  Signals.” 


F  9.9  Programming  in  Ada  With  HP-UX  Signals 

If  you  intend  to  utilize  signals  in  external  interfaced  subprograms,  refer  to 
section  F  11.7,  “Potential  Problems  Using  Interfaced  Subprograms.”  This 
version  of  HP  Ada  supports  the  association  of  an  HP-UX  signal,  such  as 
SIGINT,  with  an  Ada  signal  handling  procedure  (and  via  such  a  procedure  with 
a  task  entry).  Refer  to  section  “F  9.7  HP-UX  Signals  Used  for  Ada  Interrupt 
Entries’*  and  section  “F  12.  Interrupt  Entries”  for  additional  information. 
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F  10.  Limitations 


This  chapter  lists  limitations  of  the  compiler  and  the  Ada  development 
environment. 


F  10.1  Compiler  Limitations 


Note  It  is  impossible  to  give  exact  numbers  for  most  of  the  limits 

listed  in  this  section.  The  various  language  features  may 
interact  in  complex  ways  to  lower  the  limits. 

The  numbers  represent  “hard”  limits  in  simple  program 
fragments  devoid  of  other  Ada  features. 


F  10.  Limitations  10*1 


Description 

Maximum  number  of  tasks  is  limited  only  by  heap  size. 

Maximum  number  of  characters  in  any  path  component  of  a  file 
specified  for  access  by  the  Ada  compiler.  If  a  component  exceeds  255 
characters,  BJlKE.ERROR  will  be  raised. 

The  maximum  number  of  characters  in  the  entire  path  to  a  file 
specified  for  access  by  the  Ada  compiler.  If  the  size  of  the  entire  path 
exceeds  1023  characters,  HAME.ERROR  will  be  raised. 

The  pathname  limits  apply  to  the  entire  path  during  and  after  the 
resolution  of  symbolic  links  and  context-dependent  files  (CDFs)  if  they 
appear  in  the  specified  path. 
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F  10.2  Ada  Development  Environment  Limitations 

The  following  limits  apply  to  the  Ada  development  environment  (ada.umgr(l), 

ada.fmgrCl),  and  Ada  tools). 

Limit  Description 

200  The  number  of  characters  in  the  actual  rooted  path  of  an  Ada  program 

LIBRARY  or  FAMILY  of  libraries. 

200  The  number  of  characters  in  the  string  (possibly  after  expansion  by  an 

HP-UX  shell)  specifying  the  name  of  an  Ada  program  LIBRARY  or 
FAMILY  of  libraries.  This  limit  applies  to  strings  (pathname 
expressions)  specified  for  a  LIBRARY  or  FAMILY  that  you  submit  to  tools 
such  as  ada.niklib(l)  or  ada.umgrfl). 

512  Maximum  length  of  an  input  line  for  the  tools  ada.fmgr(l)  and 

ada.angr(l). 

255  The  maximum  number  of  characters  in  any  path  component  of  a  file 

specified  for  access  by  an  Ada  development  environment  tool.  If  a 
component  exceeds  255  characters,  NAME.ERROR  will  be  raised. 

1023  The  maximum  number  of  characters  in  the  entire  path  to  a  file 

specified  for  access  by  an  Ada  program  or  an  Ada  development 
environment  tool.  If  the  size  of  the  entire  path  exceeds  1023  characters, 
IIAME.ERROR  will  be  raised. 

The  pathname  limits  apply  to  the  entire  path  during  and  after  the 
resolution  of  symbolic  links  and  context-dependent  files  (CDFs)  if  they 
appear  in  the  specified  path. 
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F  10.3.2  Restrictions  on  TEXT_IO.FORM 

The  function  TEXT.IO.FORM  will  raise  USE.ERROR  if  it  is  called  with  either  of 
the  predefined  files  STANDARD.INPUT  or  STANDARD. OUTPUT. 


F  10.3.3  Restrictions  on  the  Smalt  of  a  Fixed  Point  Type 

A  length  clause  may  be  used  to  specify  the  value  to  use  for  ’SMALL  on  a  fixed 
point  type.  However,  this  implementation  requires  that  the  value  specified 
for  ’SMALL  is  a  power  of  two.  The  compiler  rejects  a  compilation  unit  with  a 
length  clause  specification  with  an  IMPLEMENTATION  RESTRICTION  if  ’SMALL  is 
not  an  exact  power  of  two. 


F  10.3.4  Record  Type  Alignment  Clause 

A  record  type  alignment  clause  can  specify  that  a  record  type  is  byte, 
half-word,  word,  or  double-word  aligned  (specified  as  1.  2,  4,  or  8  bytes).  Ada 
DS  does  not  support  alignments  larger  than  an  8- byte  alignment. 
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F  11.  Calling  External  Subprograms  From  Ada 


In  Ada,  parameters  of  external  interfaced  subprograms  are  passed  according 
to  the  standard  PA-RISC  calling  conventions  (see  PA-RISC  Architecture 
Procedure  Calling  Convention  Reference  Manual).  This  convention  is  used  by- 
Hewlett-Packard  for  other  language  products  on  the  HP  9000  Series  600,  700, 
and  800  family  of  computers.  The  languages  described  in  this  section  are  the 
HP  implementations  of  HP-PA  Assembler,  HP  C,  HP  FORTRAN  77,  and  HP 
Pascal  on  the  HP-UX  Series  600,  700,  and  800  systems. 

When  you  specify  the  interfaced  language  name,  that  name  is  used  to  select 
the  correct  calling  conventions  for  supported  languages.  Subprograms  written 
in  PA-RISC  Assembler,  HP  C,  HP  FORTRAN  77,  and  HP  Pascal  interface 
correctly  with  the  Ada  subprogram  caller.  This  section  contains  detailed 
information  about  calling  subprograms  written  in  these  languages.  If  the 
subprogram  is  written  in  a  language  from  another  vendor,  you  must  follow  the 
standard  calling  conventions. 

In  the  Ada  implementation  of  external  interfaced  subprograms,  the  three 
Ada  parameter  passing  modes  (in,  out,  in  out)  are  supported,  with  some 
limitations  as  noted  below.  Scalar  and  access  parameters  of  mode  in  are 
passed  by  value.  All  other  parameters  of  mode  in  are  passed  by  reference. 
Parameters  of  mode  out  or  in  out  are  always  passed  by  reference.  (See 
Table  11-1  and  section  “F  11.1.2  Access  Types”  for  details.) 
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Caution  All  array  and  record  type  parameters  are  passed  by  reference 
from  Ada  code  to  non- Ada  interfaced  code.  In  particular, 
arrays  and  records  occupying  64  bits  or  less  of  storage  are 
passed  by  reference  and  are  not  passed  by  copy,  as  by  the 
standaird  PA-RJSC  calling  convention.  Therefore,  non-Ada  code 
expecting  to  receive  such  array  or  record  parameters  must 
expect  to  receive  them  by  reference,  not  by  copy.  C  should 
declare  parameters  to  be  an  appropriate  pointer  type;  Pascal 
should  declare  parameters  to  be  VAR  parameters;  FORTRAN 
always  expects  explicit  parameters  by  reference.  Note  that 
array  and  record  type  parameters  occupying  more  that  64  bits 
of  storage  are  passed  by  reference,  both  by  Ada  and  by  the 
standard  PA-RISC  calling  convention,  and  require  no  special 
precautions. 
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F  11.  Calling  External  Subprograms  From  Ada  11-3 


Caution  Be  very  careful  to  establish  the  exact  nature  of  the  types  of 
parameters  to  be  passed.  The  bit  representations  of  these 
types  can  be  different  between  this  implementation  of  Ada  and 
other  languages,  or  between  different  implementations  of  the 
Ada  language.  Pay  careful  attention  to  the  size  of  parameters 
because  parameters  must  occupy  equal  space  in  the  interfaced 
language.  When  passing  record  types,  pay  particular  attention 
to  the  internal  organization  of  the  elements  of  a  record 
because  Ada  semantics  do  not  guarantee  a  particular  order  of 
components.  Moreover,  Ada  compilers  are  free  to  rearrange 
or  add  components  within  a  record.  See  section  “F  4.  Type 
Representation”  for  more  information. 
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F  11.1.1.1  Integer  Types 

In  Ada,  all  integers  are  represented  in  two’s  complement  form.  The 
type  SHORT_SHORT_INTEGER  is  represented  as  an  8-bit  quantity,  the  type 
SHORT.INTEGER  is  represented  as  a  16-bit  quantity,  and  the  type  INTEGER  is 
represented  as  a  32-bit  quantity. 

All  integer  types  can  be  passed  to  interfaced  subprograms.  When  an  integer  is 
used  as  a  parameter  for  an  interfaced  subprogram,  the  call  can  be  made  either 
by  reference  or  by  value.  If  passed  by  reference,  the  vadue  of  the  actual  integer 
parameter  is  not  copied  or  modified,  but  a  32-bit  address  pointer  to  the  integer 
value  is  passed.  If  passed  by  value,  a  copy  of  the  actual  integer  parameter  value 
is  passed,  based  on  its  size,  as  per  the  standard  PA-RISC  calling  convention.  If 
passed  in  a  register,  it  will  be  sign  extended  as  required.  See  sections 
“F  11.2.1.1  Integer  Types  and  Assembly  Language  Subprograms”,  “F  11.3.1.1 
Integer  Types  and  HP  C  Subprograms”,  “F  11.4.1.1  Integer  Types  and  HP 
FORTRAN  77  Subprograms”,  and  “F  11.5.1.1  Integer  Types  and  HP  Pascal 
Subprograms”for  details  specific  to  interfaced  subprograms  written  in  different 
languages. 

Integer  types  may  be  returned  as  function  results  from  external  interfaced 
subprograms. 


F  11.1.1.2  Enumeration  Types 

Values  of  an  enumeration  type  {Ada  RM .  section  3.5.1)  without  an 
enumeration  representation  clause  {Ada  RM,  section  13,3)  have  an  internal 
representation  of  the  value’s  position  in  the  list  of  enumeration  literals  defining 
the  type.  These  values  are  non-negative.  The  first  literal  in  the  list  corresponds 
to  an  integer  value  of  zero. 

An  enumeration  representation  clause  can  be  used  to  further  control  the 
mapping  of  internal  codes  for  an  enumeration  identifier.  See  section  ‘‘F  4.1 
Enumeration  Types,’’  for  information  on  enumeration  representation  clauses. 

Values  of  enumeration  types  are  represented  internally  as  either  an  8-,  16-, 
or  32-bit  quantity  (see  section  “F  4.1  Enumeration  Types”).  When  an 
enumeration  value  is  used  as  a  parameter  for  an  interfaced  subprogram,  the 
call  can  be  made  either  by  reference  or  by  value.  If  passed  by  reference,  the 
value  of  the  actual  enumeration  parameter  is  not  copied  or  modified,  but 


F  11.  Calling  External  Subprograms  From  Ada  11*7 


11 


F  11.1.1.4  Character  Types 

The  values  of  the  predefined  enumeration  type  CHARACTER  are  represented  as 
8-bit  values  in  a  range  0  through  127. 

Values  of  the  character  type  are  passed  as  parameters  and  returned  as  function 
results,  as  are  values  of  any  other  8-bit  enumeration  type. 

Character  types  may  be  returned  as  function  results  from  external  interfaced 
subprograms. 

See  sections  “F  11.2.1.4  Character  Types  and  Assembly  Language 
Subprograms”,  “F  11.3.1.4  Chcracter  Types  and  HP  C  Subprograms”, 

“F  11.4.1.4  Character  Types  and  HP  FORTRAN  77  Subprograms”,  and 
“F  11.5.1.4  Character  Types  and  HP  Pascal  Subprograms”for  details  specific  to 
interfaced  subprograms  written  in  different  languages. 
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F  11.1.2  Access  Types 

Values  of  an  access  type  (Ada  RM,  section  3.8)  have  an  internal  representation 
which  is  the  32-bit  address  of  the  underlying  designated  object. 

If  you  need  to  get  a  SYSTEM .  ADDRESS  containing  the  address  of  the  accessed 
object  and  have  the  following  declarations 

type  PTR  is  access  <something>; 

P:  PTR; 

A:  SYSTEM. ADDRESS; 
you  can  just  declare 
function  CONV  is 

new  UNCHECKED.CONVERSION  (PTR,  SYSTEM .ADDRESS) ; 
and  then  declare 
A;=  CONV(P); 

This  converts  the  pointer  into  a  SYSTEM. ADDRESS. 

An  access  type  object  has  a  value  that  is  the  address  of  the  designated  object. 
Therefore,  when  an  access  type  is  passed  by  value,  a  copy  of  this  32-bit  address 
is  passed.  If  an  access  type  object  is  passed  by  reference,  however,  the  address 
of  the  access  type  object  itself  is  passed.  This  will  effectively  force  references  to 
the  designated  object  to  be  double  indirect  references. 

See  Figure  11-1  for  details. 
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F  11.1.3  Array  Types 

In  the  HP  implementation  of  Ada,  arrays  {Ada  RM ,  section  3.6)  are  always 
passed  by  reference.  The  value  passed  is  the  address  of  the  first  element  of 
the  array.  When  an  array  is  passed  as  a  parameter  to  an  external  interfaced 
subprogram,  the  usual  checks  on  the  consistency  of  array  bounds  between 
the  calling  program  and  the  called  subprogram  are  not  enforced.  You  are 
responsible  for  ensuring  that  the  external  interfaced  subprogram  keeps  within 
the  proper  array  bounds.  You  may  need  to  explicitly  pass  the  upper  and  lower 
bounds  for  the  array  type  to  the  external  subprogram. 

The  external  subprogram  should  access  and  modify  such  an  array  in  a  manner 
appropriate  to  the  actual  Ada  type.  Note  that  Ada  will  not  range  check  the 
values  that  may  have  been  stored  in  the  array  by  the  external  subprogram. 

In  Ada,  range  checks  are  only  required  when  assigning  an  object  with  a 
constraint;  thus,  range  checks  are  not  performed  when  reading  the  value  of  an 
object  with  a  constraint.  If  an  external  subprogram  modifies  elements  in  an 
Ada  array  object,  it  has  the  responsibility  to  ensure  that  any  values  stored 
meet  the  type  constraints  imposed  by  the  Ada  type. 

Array  element  allocation,  layout,  and  alignment  are  described  in  section  “F  4.7 
Array  Types”. 

Values  of  the  predefined  type  STRING  {Ada  RM,  section  3.6.3)  are 
unconstrained  arrays  and  are  passed  by  reference  as  described  above.  The 
address  of  the  first  character  in  the  string  is  passed.  You  may  need  to  explicitly 
pass  the  upper  and  lower  bounds  or  the  length  of  the  string  to  the  external 
subprogram. 

Returning  strings  from  an  external  interfaced  subprogram  to  Ada  (such  as  OUT 
parameters)  is  not  supported.  See  section  “F  11.3.3  Array  Types  and  HP  C 
Subprograms”  for  a  complete  example  that  shows  how  to  return  STRING  type 
information  from  interfaced  subprograms. 

.A,rray  types  cannot  be  returned  as  function  results  from  external  interfaced 
subprograms.  However,  an  access  type  to  the  array  tyj>e  can  be  returned  as  a 
function  result. 
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F  11.1.4  Record  Types 

Records  {Ada  RM,  section  3.7)  are  always  passed  by  reference  in  the  HP 
implementation  of  Ada,  passing  the  32-bit  address  of  the  first  component  of 
the  record.  The  external  subprogram  should  access  an'’  '  jdify  such  a  record 
in  a  manner  appropriate  to  the  actual  Ada  type.  Note  that  Ada  will  not  range 
check  the  values  that  may  have  been  stored  in  the  record  by  the  external 
subprogram.  In  Ada,  range  checks  are  only  required  when  assigning  an  object 
with  a  constraint;  thus,  range  checks  are  not  performed  when  reading  the 
value  of  an  object  with  a  constraint.  If  an  external  subprogram  modifies  a 
component  in  an  Ada  record  object,  it  has  the  responsibility  to  ensure  that 
any  values  stored  meet  the  type  constraints  imposed  by  the  Ada  type  for  that 
component. 

When  interfacing  with  external  subprograms  using  record  types,  it  is 
recommended  that  you  provide  a  complete  record  representation  clause  for 
the  record  type.  It  is  also  your  responsibility  to  ensure  that  the  external 
subprogram  accesses  the  record  type  in  a  manner  that  is  consistent  with 
the  record  representation  clause.  For  a  complete  description  of  record 
representation  clauses,  see  section  “F  4.8  Record  Types”. 


Caution  All  record  type  parameters  are  passed  by  reference  from 

Ada  code  to  non-Ada  interfaced  code.  In  particular,  records 
occupying  64  bits  or  less  of  storage  are  passed  by  reference 
and  are  not  passed  by  copy,  as  is  the  standard  PA- RISC 
calling  convention.  Therefore,  non-Ada  code  expecting  to 
receive  such  record  parameters  must  expect  to  receive  them 
by  reference,  not  by  copy.  C  should  declare  such  parameters 
to  be  an  appropriate  pointer  type;  Pascal  should  declare 
such  parameters  to  be  VAR  parameters;  FORTRAN  always 
expects  explicit  parameters  by  reference.  Note  that  record  type 
parameters  occupying  more  than  64  bits  of  storage  are  passed 
by  reference,  both  by  Ada  and  by  the  standard  PA-RISC 
calling  convention,  and  require  no  special  precautions. 
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Direct  assignment  to  a  discriminant  of  a  record  is  not  allowed  in  Ada  {Ada 
RM,  section  3.7.1).  A  discriminant  cannot  be  passed  as  an  actual  parameter 
of  mode  out  or  in  out.  This  restriction  applies  equally  to  Ada  subprograms 
and  to  external  interfaced  subprograms  written  in  other  languages.  If  an 
interfaced  program  is  given  access  to  the  whole  record  (rather  than  individual 
components),  that  code  should  not  change  the  discriminant  value  because  that 
would  violate  the  Ada  standard  rules  for  discriminant  records. 

In  Ada,  records  are  packed  and  variant  record  parts  are  overlaid;  the  size  of 
the  record  is  the  longest  variant  part.  If  a  record  contains  discriminants  or 
composite  components  having  a  dynamic  size,  the  compiler  may  add  implicit 
components  to  the  record.  See  section  “F  4.8  Record  Types”  for  a  complete 
discussion  of  these  components. 

Dynamic  components  and  components  whose  size  depends  upon  record 
discriminant  values  are  implemented  indirectly  within  the  record  by  using 
implicit  ’  OFFSET  components. 

Record  types  cannot  be  returned  as  function  results  from  external  interfaced 
subprograms.  However,  an  access  type  to  the  record  type  can  be  returned  as  a 
function  result. 


F  11.1.5  Task  Types 

A  task  type  cannot  be  passed  to  an  external  procedure  or  external  function  as 
a  parameter  in  Ada.  A  task  type  cannot  be  returned  as  a  function  result  from 
an  external  function. 
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F  11.2.1  Scalar  Types  and  Assembly  Language  Subprograms 

See  section  “F  11.1.1  Scalar  Types”  for  details. 

F  11.2.1.1  Integer  Types  and  Assembly  Language  Subprograms 

See  section  “F  11.1.1.1  Integer  Types”  for  details. 

F  11.2.1.2  Enumeration  Types  and  Assembly  Language 

Subprograms 

See  section  “F  11.1.1.2  Enumeration  Types”  for  details. 

F  11.2.1.3  Boolean  Types  and  Assembly  Language  Subprograms 

See  section  “F  11.1.1.3  Boolean  Types”  for  details. 

F  11.2.1.4  Character  Types  and  Assembly  Language  Subprograms 

See  section  “F  11.1.1.4  Character  Types”  for  details. 

F  11.2.1.5  Real  Types  and  Assembly  Language  Subprograms 

See  section  “F  11.1.1.5  Real  Types”  for  details. 
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F  11.3  Calling  HP  C  Subprograms 

When  calling  interfaced  HP  C  subprograms,  the  form 

pragma  INTERFACE  (C ,  Ada-subprogTam.name) 

is  used  to  identify  the  need  to  use  the  HP  C  parameter  passing  conventions. 

To  call  the  following  HP  C  subroutine 

void  c.sub  (val.pann,  ref.pemn) 
int  val.pann; 
int  •ref.parm; 

•C 

} 

Ada  requires  an  interfaced  subprogram  declaration: 

procedure  C.SUB  (VAL.PARAM  :  in  INTEGER; 

REF.PARAM  :  in  out  INTEGER); 
pragma  INTERFACE  (C,  C.SUB); 

In  the  above  example  we  provided  the  Ada  subprogram  identifier  C.SUB  to  the 
pragma  INTERFACE.  If  a  pragma  INTERFACE.NAME  is  not  supplied,  the  HP  C 
subprogram  name  is  the  name  of  the  Ada  subprogram  specified  in  the  pragma 
INTERFACE,  with  all  alphabetic  characters  shifted  to  lowercase. 

Note  that  the  parameter  in  the  preceding  example,  VAL.PARAH,  must  be  of 
mode  in  to  match  the  parameter  definition  for  val.parm  found  in  the  HP  C 
subroutine.  Likewise,  REF.PARAM,  must  be  of  mode  in  out  to  correctly  match 
the  C  definition  of  *ref_pann.  Also,  note  that  the  names  for  parameters  do  not 
need  to  match  exactly.  However,  the  mode  of  access  and  the  data  type  must  be 
correctly  matched,  but  there  is  no  compile- time  or  run-time  check  that  can 
ensure  that  they  match.  It  is  your  responsibility  to  ensure  their  correctness. 

You  must  use  pragma  INTERFACE.NAME  whenever  the  HP  C  subprogram  name 
contains  characters  not  acceptable  within  Ada  identifiers  or  when  the  HP 
C  subprogram  name  contains  uppercase  letter  or  letters.  You  can  also  use 
a  pragma  INTERFACE.NAME  if  you  want  your  Ada  subprogram  name  to  be 
different  than  the  HP  C  subprogram  name. 
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F  11.3.1.1  Integer  Types  and  HP  C  Subprograms 

See  section  “F  11.1.1.1  Integer  Types”  for  details. 

When  passing  integers  by  reference,  note  that  an  Ada  SHORT_SHORT_INTEGER 
(eight  bits)  actually  corresponds  with  the  HP  C  type  char,  because  C  treats 
this  type  as  a  numeric  type. 

Table  11-2  summarizes  the  integer  correspondence  between  Ada  and  C. 


Table  11-2.  Ada  versus  HP  C  Integer  Correspondence 


Ada 

HP  C 

Bit  Length 

CHARACTER 

char 

8 

SHORT_SHORT_IHTEGER 

char 

8 

SHORT. INTEGER 

short  and  short  int 

16 

INTEGER 

int,  long,  and  long  int 

32 
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All  Ada  integer  types  are  allowed  for  the  result  returned  by  an  external 
interfaced  subprogram  written  in  HP  C  if  care  is  taken  with  respect  to 
differences  in  the  interpretation  of  8-bit  quantities. 


F  11.3.1.2  Enumeration  Types  and  HP  C  Subprograms 

See  section  “F  11.1.1.2  Enumeration  Types”  for  det^ls. 

HP  C  enumeration  types  have  the  same  representation  as  Ada  enumeration 
types.  They  both  are  represented  as  unsigned  integers  beginning  at  zero.  In 
HP  C,  the  size  of  an  enumeration  type  is  always  32  bits.  When  HP  C  passes 
enumeration  types  as  value  parameters,  the  values  are  zero  extended  to  32 
bits.  Because  Ada  also  performs  the  zero  extension  to  32  bits  for  enumeration 
type  values,  they  will  be  in  the  correct  form  for  HP  C  subprograms.  If  a 
representation  specification  applies  to  the  Ada  enumeration  type,  the  value 
specified  by  the  representation  clause  (not  the  ’POS  value)  will  be  passed  to  the 
HP  C  routine. 
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F  11.3.1.5  Real  Types  and  HP  C  Subprograms 

This  section  discusses  passing  fixed  point  types  and  floating  point  types  to 
HP  C. 


Fixed  Point  Types 

Ada  fixed  point  types  are  not  supported  as  parameters  or  as  results  of  external 
subprograms.  Ada  fixed  point  types  cannot  be  returned  as  function  results 
from  interfaced  subprograms  written  in  HP  C. 


Floating  Point  Types 

When  HP  C  is  operating  in  compatibility  mode  (non-ANSI  mode),  the 
default  calling  convention  for  passing  parameters  of  floating  point  types  by 
value  requires  that  32-bit  single  precision  reals  be  converted  to  64-bit  double 
precision  reals  before  being  passed. 

When  HP  C  is  operating  in  ANSI  conformant  mode  (or  in  compatibility 
mode  with  the  +r  flag  specified),  32- bit  single  precision  reals  are  passed  as 
parameters  without  being  converted  to  64-bit  double  precisioi. 

Consequently,  an  interface  parameter  of  type  FLOAT  or  of  a  type  derived 
from  a  type  whose  base  type  is  FLOAT,  can  only  be  passed  directly  to 
float  parameters  of  HP  C  code  compiled  in  ANSI  conformant  mode  or  in 
compatibility  mode  with  +r  specified. 

To  interface  with  compatibility  mode  HP  C  code  (no  +r  specified),  the 
Ada  type  LONG.FLOAT,  or  a  type  derived  from  a  type  whose  base  type  is 
LONG.FLOAT,  must  be  used  for  all  parameters  of  HP  C  type  float. 

This  limitation  on  passing  the  Ada  type  FLOAT  only  applies  to  parameters 
that  are  of  the  type  FLOAT  or  derived  from  a  type  whose  base  type  is  FLOAT. 

A  parameter  of  a  composite  type,  such  as  an  array  or  record,  can  have 
components  that  are  of  the  type  FLOAT.  Also,  the  type  .FLOAT  can  be  passed  by 
reference  to  an  external  HP  C  subprogram.  The  HP  C  calling  convention  does 
not  require  conversion  in  these  cases  in  any  compiler  mode. 
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HP  C  routine: 

/*  Receiving  an  Ada  string  that  has  an  ASCII. NULL  appended 
to  it  in  this  C  routine 

*f 

void  receive_ada_str  (var^str) 
char  *var_str; 

{ 

printf  ("C:  Received  value  was  :  */.s  \n",  var.str) ; 

} 


Ada  routine: 

—  passing  an  Ada  string  to  a  C  routine 

procedure  SEND.ADA.STR  is 

—  Declare  an  interfaced  procedure  that  sends  an 
--  Ada-String  to  a  C-subprogram 

procedure  RECEIVE.ADA.STR  (  VAR.STR  :  STRING) ; 
pragma  INTERFACE  (C,  RECEIVE.ADA.STR); 

begin  —  SEND.ADA.STR 

—  Test  the  passing  of  an  Ada  string  to  a  C  routine 
RECEIVE.ADA.STR  (  "Ada  test  string  sent  to  C  "  4  ASCII. NUL); 

end  SEND.ADA.STR; 
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—  Declare  an  interfaced  procedure  that  returns  a  pointer 

—  to  a  C  string  (actually  a  pointer  to  a  character) 
function  SEND.C.STR  return  C.STRING; 

pragma  INTERFACE  (C,  SEND.C.STR) ; 

function  FETCH.CHAR  is 

new  SYSTEM. FETCH.FROM. ADDRESS  (TARGET  =>  CHARACTER); 

—  Create  a  non-generic  instantiation  of  the  function  FETCH 

function  C.STRING. LENGTH  (SRC  :  C.STRING)  return  NATURAL  is 
use  SYSTEM;  —  import  the  (address .offset)  operator 
LEN  :  NATURAL  :=  0; 

START  :  SYSTEM . ADDRESS ; 

CUR  :  CHARACTER; 
begin 

START  ;=  SRC . all ’ADDRESS; 
loop 

CUR  :=  FETCH.CHAR  (FROM  =>  START  ♦  OFFSET  (LEN)); 
exit  when  CUR  *  ASCII. NUL; 

LEN  ;=  LEN  +  1; 
end  loop; 
return  LEN; 
end  C.STRING.LENGTH; 


I 
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function  CONVERT.TO.ADA  (SRC  ;  C.STRING)  return  A.STRING  is 
use  SYSTEM;  —  import  the  "+" (address, off set)  operator 

A.STORAGE  :  A.STRING; 

LEN  :  NATURAL; 

C.START  :  SYSTEM . ADDRESS ; 

C.CUR  :  CHARACTER; 

begin 

LEN  :=  C.STRING.LENGTH  (SRC); 

A.STORAGE  :=  new  STRING  (1  ..  LEN); 

C.START  : =  SRC . all ' ADDRESS ; 
for  INX  in  0  ..  LEN  -  1  loop 

C.CUR  :=  FETCH.CHAR  (FROM  =>  C.START  +  OFFSET  (INX)); 
A.STORAGE. all  (INX  +  1)  :=  C.CUR; 
end  loop; 
return  A.STORAGE; 
end  CONVERT.TO.ADA; 


begin  --  Start  of  READ.C.STRING 
declare 

A.RESULT  :  A.STRING; 

C.RESULT  :  C.STRING; 
begin 

—  Call  the  external  C  subprogram 
C.RESULT  :=  SEND.C.STR; 

—  Convert  to  an  access  Ada  STRING 
A.RESULT  CONVERT.TO.ADA  (  C.RESULT  ); 

—  Print  out  the  result. 
TEXT.IO.PUT.LINE(  A.RESULT. all  ); 
end ; 

end  READ.C.STRING; 
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—  Declare  an  interfaced  procedure  that  returns  a  pointer 

—  to  a  C  string  (actually  a  pointer  to  a  character) 
fxinction  SEND_C_STR  return  C.STRING; 

pragma  INTERFACE  (C.  SESD.C.STR) ; 

function  FETCH_CHAR  is 

new  SYSTEM. FETCH.FROM. ADDRESS  (TARGET  *>  CHARACTER); 

—  Create  a  non-generic  instantiation  of  the  function  FETCH 

function  C.STRING.LENGTH  (SRC  :  C.STRING)  return  NATURAL  is 
use  SYSTEM;  —  import  the  (address .off set)  operator 
LEN  :  NATURAL  :=  0; 

START  :  SYSTEM . ADDRESS ; 

CUR  :  CHARACTER; 
begin 

START  :=  SRC. all ’ADDRESS; 
loop 

CUR  ;=  FETCH.CHAR  (FROM  =>  START  +  OFFSET  (LEN)); 
exit  when  CUR  =  ASCII.NUL; 

LEN  :*  LEN  +  1; 
end  loop; 
return  LEN; 
end  C.STRING.LENGTH; 
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F  11.3.4  Record  Types  and  HP  C  Subprograms 

See  section  “F  11.1.4  Record  Types”  for  details. 

Ada  records  can  be  passed  as  parameters  to  external  interfaced  subprograms 
written  in  HP  C  if  care  is  taken  regarding  the  record  layout  and  access  to 
record  discriminant  values.  See  section  “F  4.8  Record  Types”  for  information 
on  record  type  layout. 
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F11.4  Calling  HP  FORTRAN  77  Language  Subprograms 

When  calling  interfaced  HP  FORTRAN  77  subprograms,  the  following  form  is 
used: 

pragma  INTERFACE  (FORTRAN,  Ada-subprogmm.name) 

This  form  is  used  to  identify  the  need  for  HP  FORTRAN  77  parameter  passing 
conventions. 

To  call  the  HP  FORTRAN  77  subroutine 

SUBROUTINE  fsub  (pann) 

INTEGER*4  pann 


END 

you  need  this  interfaced  subprogram  declaration  in  Ada: 

procedure  FSUB  (PARK  :  in  out  INTEGER) ; 
pragma  INTERFACE  (FORTRAN,  FSUB); 

The  e,\ternal  name  specified  in  the  Ada  interface  declaration  can  be  any  Ada 
identifier.  If  the  Ada  identifier  differs  from  the  FORTR.AN  77  subprogram 
name,  pragma  INTERFACE.NAME  is  required. 

Note  that  the  parameter  in  the  example  above  is  of  mode  in  out.  In 
HP  FORTRAN  77,  all  user-declared  parameters  are  always  passed  by  reference; 
therefore,  mode  in  out  or  mode  out  must  be  used  for  scalar  type  parameters. 
The  HP  FORTR.4N  77  compiler  might  expect  some  implicit  parameters  that 
are  passed  by  value  And  not  by  reference.  See  section  “F  11.4.4  String  Types 
and  HP  FORTRAN  77  Subprograms"  for  details. 

Only  scalar  types  (integer,  floating  point,  and  character  types)  are  allowed  for 
the  result  returned  by  an  external  interfaced  function  subprogram  written 
in  HP  FORTRAN  77.  Access  type  results  are  not  supported.  For  more 
information,  see  the  following  manuals: 

■  BP  FORTRAN  77/HP-UX  Reference  Manual 
m  HP  FORTRAN  77/HP-UX  Programmer's  Reference 
m  HP  FORTRAN  77/Quick  Reference  Guide 

For  general  information  about  passing  types  to  interfaced  subprograms,  see 
section  “F  11.1  General  Considerations  in  Passing  Ada  Types". 
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F  11.4.1  Scalar  Types  and  HP  FORTRAN  77  Subprograms 

FORTRAN  expects  all  user-declaied  parameters  to  be  passed  by  reference. 

Ada  scalar  type  parameters  will  only  be  passed  by  reference  if  declared  as 
mode  in  out  or  out;  therefore,  no  scalar  type  parameters  to  a  FORTRAN 
interface  routine  should  be  declared  as  mode  in  (except  for  certain  implicit 
parameters;  see  section  “F  11.4.4  String  Types  and  HP  FORTRAN  77 
Subprograms”  for  details.)  No  error  will  be  reported  by  Ada,  but  you  will  most 
likely  get  unexpected  results. 


F  11.4.1.1  Integer  Types  and  HP  FORTRAN  77  Subprograms 

See  section  “F  11.1.1.1  Integer  Types”  for  details. 

See  section  “F  11.1.1  Scalar  Types”  for  details. 

Table  11-3  summarizes  the  correspondence  between  integer  types  in  Ada  and 
HP  FORTRAN  77. 


Table  11-3. 

Ada  versus  HP  FORTRAN  77  Integer  Correspondence 


Ada 

HP  FORTRAN  77 

Bit  Length 

SHORT.SHORT.INTEGER 

BYTE 

8 

SHORT.INTEGER 

INTEGER*2 

16 

INTEGER 

INTEGER*4 

32 

The  compatible  types  are  the  same  for  procedures  and  functions.  Compatible 
Ada  integer  types  are  allowed  for  the  result  returned  by  an  external  interfaced 
function  subprogram  written  in  HP  FORTR.AN  77. 

Ada  semantics  do  not  allow  parameters  of  mode  in  out  to  be  passed  to 
function  subprograms.  Therefore,  for  Ada  to  call  HP  FORTR.\N  77  external 
interfaced  function  subprograms,  each  scalar  parameter's  address  must  be 
passed.  The  use  of  the  supplied  package  SYSTEM  facilitates  this  passing  of  the 
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object’s  address.  The  parameters  in  an  HP  FORTRAN  77  external  function 
must  be  declared  as  in  the  example  below: 

with  SYSTEM; 

VALl  :  INTEGER;  —  a  scalar  tjrpe 
VAL2  :  FLOAT  ;  —  a  scalar  type 
RESULT  :  INTEGER; 

function  FTNFUNC  (PARMl,  PARM2  :  SYSTEM. ADDRESS)  return  INTEGER; 
The  external  function  must  be  called  from  within  Ada  as  follows: 

RESULT  :=  FTNFUNC  (VALl ’ADDRESS,  VAL2 ’ ADDRESS ) ; 


F  11.4.1.2  Enumeration  Types  and  HP  FORTRAN  77  Subprograms 

See  section  “F  11.1.1.2  Enumeration  Types”  for  details. 

The  HP  FORTRAN  77  language  does  not  support  enumeration  types. 
However,  objects  that  are  elements  of  an  Ada  enumeration  type  can  be  passed 
to  an  HP  FORTRAN  77  integer  type  because  the  underlying  representation 
of  an  enumeration  type  is  an  integer.  The  appropriate  FORTRAN  type 
(BYTE,  INTEGER*2,  or  INTEGER*4)  should  be  chosen  to  match  the  size  of  the 
Ada  enumeration  type.  If  a  representation  specification  applies  to  the  Ada 
enumeration  type,  the  value  specified  by  the  representation  clause  (not  the 
’POS  value)  will  be  passed  to  the  FORTR.4N  routine. 
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F  11.4.1.3  Boolean  Types  and  HP  FORTRAN  77  Subprograms 

See  section  “F  11.1.1.3  Boolean  Types”  for  details. 

An  Ada  Boolean  that  has  the  default  8-bit  size  is  compatible  with  the  default 
mode  HP  FORTRAN  77  type  LOGICAL*!  both  as  a  parameter  and  as  a 
function  result. 

An  Ada  Boolean  type  with  a  representation  specification  for  a  larger  size  (16 
or  32  bits)  is  not  compatible  with  the  larger  sized  HP  FORTRAN  77  logical 
types  (L0GICAL*2  or  L0GICAL*4).  Such  Ada  Booleans  can  be  passed  to  the 
appropriately  sized  FORTRAN  integer  type  (INTEGER*2  or  INTEGER*4)  and 
treated  as  integers  that  have  the  value  of  *P0S  of  the  Ada  Boolean  value. 

If  the  HP  FORTRAN  77  routine  is  compiled  with  one  of  the  HP  FORTRAN  77 
options  that  changes  the  size  or  representation  of  logical  types  to  other 
than  the  default,  you  will  have  to  determine  what  Ada  types,  if  any,  are 
compatible  with  the  altered  FORTR.4N  behavior  by  consulting  the  appropriate 
FORTRAN  documentation. 
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F  11.4.1.4  Character  Types  and  HP  FORTRAN  77  Subprograms 

See  section  “F  11.1.1.4  Character  Types”  for  details. 

There  is  no  one-to-one  mapping  between  an  Ada  character  type  and  any 
HP  FORTRAN  77  character  type.  An  Ada  character  type  can  be  passed  to 
HP  FORTRAN  77  or  returned  from  HP  FORTRAN  77  using  one  of  several 
methods. 

HP  FORTRAN  77  considers  all  single  character  parameters  to  be 
single-element  character  arrays.  The  method  that  HP  FORTRAN  77  uses  to 
pass  character  arrays  is  described  in  section  “F  11.4.4  String  Types  and  HP 
FORTRAN  77  Subprograms”.  The  method  requires  that  an  implicit  value 
parameter  be  passed  to  indicate  the  size  of  the  character  array.  Because  HP 
FORTRAN  77  uses  this  method  for  passing  character  types,  it  might  be  more 
convenient  to  convert  Ada  character  types  into  Ada  strings  and  follow  the  rules 
that  govern  passing  Ada  string  types  to  HP  FORTRAN  77. 

An  Ada  character  that  has  the  default  8-bit  size  can  be  passed  to  a  default 
mode  HP  FORTRAN  77  parameter  of  type  CHARACTER*!.  This  can  be  done 
if  the  interface  declaration  specifies  the  additional  size  parameters  that 
HP  FORTRAN  77  implicitly  expects  and  passes  the  constant  value  one  (the 
size  of  the  character)  when  the  HP  FORTRAN  77  subprogram  is  called.  See 
section  “F  11.4.4  String  Types  and  HP  FORTRAN  77  Subprograms”  for 
an  example  of  implicit  size  parameters  for  strings;  to  pass  an  Ada  character 
instead  of  a  string,  simply  use  the  Ada  character  type  in  the  Ada  interface 
declaration  in  place  of  the  .\da  string  type  and  CHARACTER*!  in  the  HP 
FORTRAN  77  declaration  in  place  of  the  CHARACTER  *(*).  Note  that  the 
size  parameter  or  parameters  are  not  specified  in  the  HP  FORTRAN  77 
subprogram  declaration;  they  are  implicit  parameters  that  are  expected  by  the 
HP  FORTRAN  77  subprogram  for  each  character  array  (or  character)  type 
parameter. 

An  Ada  character  type  that  has  the  default  size  cannot  be  returned  from  an 
HP  FORTR.AN  77  function  that  has  a  result  type  of  CHARACTER*!  (it  can  be 
returned  as  a  BYTE;  see  below  for  details). 

An  Ada  character  type  that  has  the  default  8-bit  size  can  also  be  passed  to 
an  HP  FORTR.AN  77  parameter  of  type  BYTE  without  having  to  pass  the 
additional  length  parameter.  The  BYTE  will  have  the  value  of  ’POS  of  the  .Ada 
character  value. 
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An  Ada  character  type  that  has  the  default  size  can  also  be  returned  from  an 
HP  FORTRAN  77  function  that  has  a  return  type  of  BYTE.  The  BYTE  to  be 
returned  should  be  assigned  the  *P0S  vadue  of  the  desired  Ada  character. 

An  Ada  character  type  with  a  representation  specification  for  a  larger  size  (16 
or  32  bits)  is  not  compatible  with  any  HP  FORTRAN  77  character  type.  Such 
Ada  characters  can  be  passed  to  the  appropriately  sized  FORTRAN  integer 
type  (INTEGER*2  or  INTEGER»4)  and  treated  as  integers  that  have  the  value  of 
’POS  of  the  Ada  character  value. 


F  11.4.1.S  Real  Types  and  HP  FORTRAN  77  Subprograms 

This  section  discusses  passing  fixed  and  floating  point  types  to  subprograms 
written  in  FORTRAN. 


Fixed  Point  Types 

Ada  fixed  point  types  are  not  supported  as  parameters  or  as  results  of  external 
interfaced  subprograms  written  in  HP  FORTRAN  77.  Ada  fixed  point  types 
cannot  be  returned  as  function  results  from  external  interfaced  subprograms 
written  in  HP  FORTRAN  77. 


Floating  Point  Types 

See  section  “F  11.1.1.5  Real  Types’’  for  details. 

.The  Ada  type  FLOAT  corresponds  to  the  REAL*4  format  in  HP  FORTRAN  77. 
The  Ada  type  LONG.FLOAT  corresponds  to  the  HP  FORTR.4N  77  type  DOUBLE 
PRECISION  (or  REAL*8). 

There  is  no  Ada  type  that  corresponds  to  the  HP  FORTRAN  77  type  REAL*  16. 
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F  11.4.2  Access  Types  and  HP  FORTRAN  77  Subprograms 

See  section  “F  11.1.2  Access  Types”  for  details. 

Ada  access  types  have  no  meaning  in  HP  FORTRAN  77  subprograms  because 
the  types  are  address  pointers  to  .4da  objects.  The  implementation  value  of 
an  Ada  parameter  of  type  ACCESS  may  be  passed  to  an  HP  FORTRAN  77 
procedure.  The  parameter  in  HP  FORTRAN  77  is  seen  as  INTEGER*4. 

The  object  pointed  to  by  the  access  parameter  has  no  significance  in 
HP  FORTRAN  77;  the  access  parameter  value  itself  would  be  useful  only  for 
comparison  operations  to  other  accesi;  values. 

HP  FORTRAN  77  can  return  an  INTEGER*4  and  the  Ada  program  can  declare 
an  access  type  as  the  returned  value  type  (it  will  be  a  matching  size  because  in 
Ada,  an  access  type  is  a  32-bit  quantity.)  However,  care  should  be  taken  that 
the  returned  value  can  actually  be  used  by  Ada  in  a  meaningful  manner. 
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F  11.4.3  Array  Types  and  HP  FORTRAN  77  Subprograms 

See  section  “F  11.1.3  Array  Types”  for  details. 

Arrays  whose  components  have  an  HP  FORTRAN  77  representation  can  be 
passed  as  parameters  between  Ada  and  interfaced  external  HP  FORTRAN  77 
subprograms.  For  example,  Ada  arrays  whose  components  are  of  types 
INTEGER,  SHORT.INTEGER,  FLOAT,  LONG.FLOAT,  or  CHARACTER  may  be  passed  as 
parameters. 

Array  types  cannot  be  returned  as  function  results  from  external 
HP  FORTRAN  77  subprograms.  However,  an  access  type  to  the  array  type  can 
be  returned  as  a  function  result. 


Caution  Arrays  with  multiple  dimensions  are  implemented  differently 
in  Ada  and  HP  FORTRAN  77.  To  obtain  the  same  layout  of 
components  in  memory  as  a  given  HP  FORTRAN  77  array,  the 
Ada  equivalent  must  be  declared  and  used  with  the  dimensions 
in  reverse  order. 
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Consider  the  components  of  a  2-row  by  3-column  matrix,  declared  in 
HP  FORTRAN  77  as 

INTEGER*4  a(2.3) 

or 

INTEGER*4  a( 1:2, 1:3) 

This  array  would  be  stored  by  HP  FORTRAN  77  in  the  following  order: 

aCl.l),  a(2,l).  a(1.2).  a(2.2).  a(l,3).  a(2,3) 

This  is  referred  to  as  storing  in  column  major  order;  that  is,  the  first  subscript 
varies  most  rapidly,  the  second  varies  next  most  rapidly,  and  so  forth,  and  the 
last  varies  least  rapidly. 

Consider  the  components  of  a  2-row  by  3-column  matrix,  declared  in  Ada  as: 

A  :  array  (l.,2,  1..3)  of  INTEGER; 

This  array  would  be  stored  by  Ada  in  the  following  order: 

A(1.2).  Ad. 3).  A(2,l).  A(2,2).  A(2,3) 

This  is  referred  to  as  storing  in  row  major  order;  that  is,  the  last  subscript 
varies  most  rapidly,  the  ne.xt  to  last  varies  next  most  rapidly,  and  so  forth, 
while  the  first  varies  least  rapidly.  Clearly  the  two  declarations  in  the  different 
languages  are  not  equivalent.  Now.  consider  the  components  of  a  2-row  by 
3-column  matrix,  declared  in  Ada  as; 

A  :  array  d..3,  1..2)  of  INTEGER; 

Note  the  reversed  subscripts  compared  with  the  FORTRAN  declaration.  This 
array  w’ould  be  stored  by  Ada  in  the  following  order: 

Ad.l),  Ad,2),  A(2,l).  A(2.2),  A(3.1),  A(3,2) 

If  the  subscripts  are  reversed,  the  layout  would  be 

Ad.l),  A(2,l),  Ad. 2).  A(2.2).  Ad. 3).  A(2,3) 

which  is  identical  to  the  HP  FORTR.A.N  77  layout.  Thus,  either  of  the 
language  declarations  could  declare  its  component  indices  in  reverse  order  to  be 
compatible. 
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To  illustrate  that  equivalent  multi-dimensional  arrays  require  a  reversed  order 
of  dimensions  in  the  declarations  in  HP  FORTRAN  77  and  Ada,  consider  the 
following: 

The  Ada  statement 

FOO  :  array  (1. .10,1. .5.1. .3)  of  FLOAT; 
is  equivalent  to  the  HP  FORTRAN  77  declaration 
REAL*4  F00(3,5,10) 
or 

REALM  F00(l:3, 1:5, 1:10) 

Both  Ada  and  HP  FORTRAN  77  store  a  one-dimensional  array  as  a  linear  list. 


F  11.4.4  String  Types  and  HP  FORTRAN  77  Subprograms 

When  a  string  item  is  passed  as  an  argument  to  an  HP  FORTRAN  77 
subroutine  from  within  HP  FORTR.\N  77,  extra  information  is  transmitted 
in  hidden  (implicit)  parameters.  The  calling  sequence  includes  a  hidden 
parameter  (for  each  string)  that  is  the  actual  length  of  the  .\SCII  character 
sequence.  This  implicit  parameter  is  passed  in  addition  to  the  address  of  the 
.A.SCI1  character  string.  The  hidden  parameter  is  passed  by  value,  not  by 
reference. 

These  conventions  are  different  from  those  of  Ada.  For  an  Ada  program  to  call 
an  external  interfaced  subprogram  written  in  HP  FORTRAN  77  with  a  string 
type  parameter,  you  must  explicitly  pass  the  length  of  the  string  object.  The 
.length  must  be  declared  as  an  Ada  32-bit  integer  parameter  of  mode  in. 
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The  following  example  illustrates  the  declarations  needed  to  call  an  external 
subroutine  having  a  parameter  profile  of  two  strings  and  one  floating  point 
variable. 

procedure  FTNSTR  is 

SA:  STRINGCl. .6):=  "ABCDEF"; 

SB:  STRINGCl. .2):=  "GH"; 

FLOAT.VAL:  FLOAT :=  1.5; 

LENGTH.SA,  LENGTH.SB  :  INTEGER; 


procedure  FEXSTR  (  SI  :  STRING; 

LSI  :  in  INTEGER; 

F  :  in  out  FLOAT; 
S2  :  STRING; 

LS2  :  in  INTEGER); 

pragma  INTERFACE  (FORTRAN,  FEXSTR); 


—  passed  by  reference 

—  len  of  string  SI, 

—  must  be  IN 

—  must  be  IN  OUT 

—  passed  by  reference 

—  len  of  string  S2, 

—  must  be  IN 


begin  —  procedure  FTNSTR 
LENGTH.SA  :*  SA' LENGTH; 

LENGTH.SB  :=  SB 'LENGTH; 

FEXSTR  (SA,  LENGTH.SA,  FLOAT.VAL,  SB,  LENGTH.SB); 
end  FTNSTR; 


Note  Note  that  the  string  lengths  immediately  follow  the 

corresponding  string  parameter.  The  string  lengths  must  be 
passed  by  value,  not  by  reference. 
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The  HP  FORTRAN  77  external  subprogram  is  the  following: 

SUBROUTINE  Fextr  (si.  r,  s2) 

CHARACTER  *(*)  si,  s2 
REAL+4  r 

END 
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Returning  A  String  From  FORTRAN 

It  is  not  possible  to  declare,  in  Ada,  an  external  FORTRAN  function 
that  returns  a  result  of  type  STRING  (character*N  or  chEa'acter*(*)  in 
FORTRAN).  However,  such  a  FORTRAN  function  can  be  accessed  from  Ada 
by  declaring  th  mction  to  be  an  Ada  procedure  with  two  additional  initial 
parameters.  The  first  parameter  should  be  declared  as  an  out  parameter  of 
a  constrained  string  type;  the  second  parameter  should  be  declared  as  an  in 
parameter  of  type  INTEGER.  The  string  that  is  to  hold  the  result  is  passed  as 
the  first  parameter,  and  the  length  of  that  first  parameter  (the  number  of 
characters  that  FORTRAN  can  safely  return  in  that  first  parameter  string)  is 
passed  as  the  second  parameter. 

If  the  maocimum  number  of  characters  specified  by  the  second  parameter  is 
greater  than  the  number  of  characters  in  the  string  being  returned  as  the 
FORTRAN  function  result,  the  Ada  string  will  be  padded  with  blanks  out  to 
the  number  of  characters  specified  as  the  second  parameter.  If  the  ma,\imum 
number  of  characters  specified  by  the  second  parameter  is  less  than  the 
number  of  characters  in  the  string  being  returned  as  the  FORTRAN  function 
result,  only  the  number  of  characters  specified  as  the  second  parameter  will  be 
•returned  in  the  Ada  string. 
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The  following  Ada  program  calls  a  FORTRAN  function  that  returns  a  STRING 
function  result: 


procedure  FORTRAN.STRING.FUNC  is 

subtype  RESULT  is  STRING  (1..80) 

procedure  FORTRAN.FOO  (RES:  out  RESULT; 

MAX:  in  INTEGER; 

X  :  in  out  INTEGER; 

Y  :  in  out  INTEGER); 

pragma  INTERFACE  (FORTRAN,  FORTRAN  FOO) ; 

pragma  INTERFACE.NAME  (FORTRAN.FOO,  ■•foo’’); 

S  :  RESULT; 

A  :  INTEGER; 

B  :  INTEGER; 

begin  —FORTRAN.STRING.FUNC 
A  :*  28; 

B  :*  496; 

FORTRAN.FOO  (S,  S’ LENGTH,  A,  B); 
end  FORTRAN.STRING.FUNC; 


The  FORTRAN  function  looks  like  this: 

CHARACTER  *(•)  FUNCTION  foo  (x,y) 
INTEGER*4  x,y 

foo  =  ’RETURN  THIS  STRING  TO  ADA’ 

RETURN 

END 
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F  11.4.5  Record  Types  and  HP  FORTRAN  77  Subprograms 

See  section  “F  11.1.4  Record  Types”  for  details. 

Ada  records  may  be  passed  as  parameters  to  external  interfaced  subprograms 
written  in  HP  FORTRAN  if  care  is  taken  regarding  the  record  layout  and 
access  to  record  discriminant  values.  See  section  “F  4.8  Record  Types”  for 
information  on  record  type  layout. 

Record  types  are  not  allowed  as  function  results  in  HP  FORTRAN  functions. 

F  11.4.6  Other  FORTRAN  Types 

The  HP  FORTRAN  77  types  COMPLEX,  CDMPLEX+8,  DOUBLE  COMPLEX,  and 
COMPLEX*  16  have  no  direct  counterparts  in  Ada.  However,  it  is  possible  to 
declare  equivalent  types  using  either  an  Ada  array  or  an  Ada  record  type.  For 
example,  with  type  COMPLEX  in  HP  FORTRAN  77,  a  simple  Ada  equivalent  is  a 
user-defined  record: 

type  COMPLEX  is 
record 

Real  :  FLOAT; 

Imag  :  FLOAT ; 
end  record; 

Similarly,  an  HP  FORTRAN  77  double  complex  number  could  be  represented 
with  the  two  record  components  declared  as  Ada  type  LDNG.FLOAT. 

While  it  is  not  possible  to  declare  an  Ada  external  function  that  returns  the 
above  record  type,  an  Ada  procedure  can  be  declared  with  an  out  parameter 
•of  type  COMPLEX.  The  .Ada  procedure  would  then  need  to  interface  with  an 
HP  FORTR.AN  77  subroutine,  which  would  pass  the  result  back  using  an  in 
out  or  out  parameter. 
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F  11.5  Calling  HP  Pascal  Language  Subprograms 

When  calling  interfaced  HP  Pascal  subprograms,  the  form 

pragma  INTERFACE  (Pascal,  Adasubprogram-name) 

is  used  to  identify  the  need  to  use  the  HP  Pascal  parameter  passing 
conventions. 

To  call  the  following  HP  Pascal  subroutine 

module  modp; 
export 

procedure  p.subr  (val.parm  :  integer; 

var  ref _parm  :  integer) ; 


implement 

procedure  p.subr  (val.parm  :  integer; 

var  ref _pann  :  integer) ; 

begin 


end; 

end. 

Ada  would  use  the  interfaced  subprogram  declaration; 

procedure  P.SUB  (VAL.PARAM  :  in  INTEGER; 

REF.PARAM  :  in  out  INTEGER); 
pragma  INTERFACE  (Pascal,  P.SUB); 

In  the  above  example  we  provided  the  Ada  subprogram  identifier  P.SUB  to  the 
pragma  INTERFACE. 

Note  that  the  parameter  in  the  example,  VAL.PARAM,  must  be  of  mode  in 
to  match  the  parameter  definition  for  val.parm  found  in  the  HP  Pascal 
subroutine.  Likewise.  REF.PARAM,  must  be  of  mode  in  out  to  correctly  match 
the  HP  Pascal  definition  of  var  ref  .parrn.  Also,  note  that  the  names  for 
parameter.'  do  not  need  to  match  exactly.  However,  the  mode  of  access  and  the 
data  type  must  be  correctly  matched,  but  there  is  no  compile-time  or  run-time 
check  that  can  ensure  that  they  match.  It  is  your  responsibility  to  ensure  their 
correctness. 
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When  Ada  interfaces  to  HP  Pascal,  it  refers  to  the  HP  Pascal  procedure 
or  function  by  the  procedure  or  function  name.  In  the  above  example,  the 
pragma  INTERFACE  was  sufficient  to  specify  that  name,  although  a  pragma 
INTERFACE.NAME  could  also  have  been  used  (and  would  be  necessary  if  the 
name  given  to  the  Ada  routine  did  not  map  correctly  to  the  desired  HP  Pascal 
name).  Because  Ada  uses  only  the  HP  Pascal  procedure  or  function  name, 
there  is  a  difficulty  if  that  name  is  not  unique. 

The  names  of  the  procedures  and  functions  declared  within  an  HP  Pascal 
module  must  be  unique  within  a  single  module.  A  given  module  can  only 
contain  one  procedure  or  function  name  (for  example,  FOO),  but  another 
module  could  also  contain  a  procedure  or  function  named  FOO.  If  a  single 
program  uses  both  modules,  it  is  necessary  to  properly  resolve  references  to 
FOO.  To  properly  resolve  such  references,  procedure  and  function  names  in 
modules  are  qualified  with  the  name  of  the  module  that  contains  them.  This 
qualification  is  internal  to  the  object  file  and  is  not  accessible  to  user  code. 

The  linker  (ld(l))  uses  the  qualification  information  to  resolve  references  by 
HP  Pascal  code  to  identically  named  procedures  or  functions. 

This  qualification  mechanism  poses  a  difficulty  when  attempting  to  interface 
Ada  to  HP  Pascal  because  Ada  can  only  specify  the  unqualified  HP  Pascal 
procedure  or  function  name.  There  will  be  no  difficulty  if  the  HP  Pascal 
procedure  or  function  being  called  has  a  name  that  is  unique  within  all  the 
HP  Pascal  modules  used  in  the  Ada  program  (if  the  qualification  mechanism 
is  not  needed  for  the  name).  If  the  procedure  or  function  name  is  not  unique, 
the  linker  (ld(l))  will,  without  producing  an  error  or  warning,  select  one 
(usually  the  first  one)  of  the  multiple  HP  Pascal  procedures  or  functions  that 
it  encounters  during  the  link  that  has  the  name  specified  by  Ada.  As  this 
.unpredictable  selection  is  likely  to  lead  to  an  incorrect  program,  interfacing 
to  HP  Pascal  procedures  or  functions  that  are  not  uniquely  named  is  not 
recommended. 

For  more  information  on  Pascal  interfacing,  see  the  HP  Pascal/HP-UX 
Reference  Manval.  Additional  information  is  available  in  the  HP-UX 
Portability  Guide. 

For  Pascal,  scalar  and  access  parameters  of  mode  in  are  passed  by  value; 
the  value  of  the  parameter  object  is  copied  and  passed.  .411  other  types  of  in 
parameters  (arrays  and  records)  and  parameters  of  mode  out  and  in  out  are 
passed  be  reference;  the  address  of  the  object  is  passed.  This  means  that,  in 
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general,  Ada  in  parameters  correspond  to  Pascal  value  parameters,  while 
Pascal  var  parameters  correspond  to  the  Ada  parameters  of  either  mode  in  out 
or  mode  out. 

Only  scalar  types  (integer,  floating  point,  character.  Boolean,  and  enumeration 
types)  and  access  types  are  allowed  for  the  result  returned  by  an  external 
interfaced  Pascal  function  subprograms. 

For  general  information  about  passing  parameters  to  interfaced  subprograms, 
see  section  “F  11.1  General  Considerations  in  Passing  Ada  Types”. 


F  11.5.1  Scalar  Types  and  HP  Pascal  Subprograms 

See  section  “F  11.1.1  Scalar  Types”  for  details. 

F  11.5.1.1  Integer  Types  and  HP  Pascal  Subprograms 

See  section  “F  11.1.1.1  Integer  Types”  for  details. 

Integer  types  are  compatible  between  Ada  and  HP  Pascal  provided  their  ranges 
of  values  are  identical.  Table  11-4  shows  corresponding  integer  types  in  Ada 
and  HP  Pascal. 


Table  11-4.  Ada  versus  HP  Pascal  Integer  Correspondence 


Ada 

HP  Pascal 

Bit  Length 

predefined  type  INTEGER 

predefined  type  integer 

32 

predefined  type 
SHORT.INTEGER 

predefined  type  shorlint  or 
user  type  116  =  0  . 6553.5; 

16 

predefined  type 
SHORT_SHORT_INTEGER 

user-defined  type 
type  18  =  0..255; 

8 
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Note 


In  HP  Pascal,  any  integer  subrange  that  has  a  negative  lower 
bound  is  always  implemented  in  32  bits.  Integer  subranges 
with  a  non-negative  lower  bound  are  implemented  in  8-bits  if 
the  upper  bound  is  255  or  less,  in  16-bits  if  the  upper  bound 
is  65535  or  less,  and  in  32-bits  if  the  upper  bound  is  greater 
than  65535.  Therefore,  in  table  Table  11-4,  the  user-defined 
subrange  0  . . .  255  is  shown  as  the  HP  Pascal  equivalent  to  the 
Ada  type  SHORT_SHORT_INTEGER;  however,  the  Ada  type  is  a 
signed  type  with  the  range  -128. .127.  To  convert  the  unsigned 
value  back  to  a  signed  value  in  HP  Pascal,  if  the  unsigned  value 
is  greater  than  127,  you  will  need  to  subtract  256  to  obtain  the 
actual  negative  value. 


Whether  passed  from  Ada  to  HP  Pascal  by  value  or  by  reference,  the 
appropriate  HP  Pascal  type,  as  shown  in  Table  11-4,  must  be  used  to  properly 
access  the  Ada  integer  value  from  HP  Pascal. 

All  Ada  integer  types  are  allowed  for  the  result  returned  by  an  external 
interfaced  subprogram  written  in  HP  Pascal  if  care  is  taken  with  respect  to 
ranges  defined  for  integer  quantities. 


F  11.  Calling  External  Subprograms  From  Ada  11-49 


F  11.5.1.2  Enumeration  Types  and  HP  Pascal  Subprograms 

See  section  “F  11.1.1.2  Enumeration  Types”  for  details. 

Ada  and  HP  Pascal  have  similar  implementations  of  enumeration  types.  In 
Ada  and  HP  Pascal,  enumeration  types  can  have  a  size  of  8, 16,  or  32  bits. 
However,  Ada  normally  considers  enumeration  types  to  be  signed  quantities 
and  HP  Pascal  considers  them  to  be  unsigned.  Table  11-5  shows  corresponding 
enumeration  types  in  Ada  and  HP  Pascal. 


Table  11-5.  Ada  versus  HP  Pascal  Enumeration  Correspondence 


Ada 

HP  Pascal 

Bit  length 

<=  128  elements 

<=  256  elements 

8 

<=  32768  elements 

<=  63336  elements 

16 

>  32768  elements 

>  65536  elements 

32 

If  the  Ada  enumeration  type  has  129  through  256  elements  or  32769  through 
65536  elements,  there  are  additional  requirement  to  passing  or  returning  values 
of  such  an  Ada  type.  A  size  specification  on  a  representation  clause  for  the 
Ada  enumeration  type  should  be  used  to  specify  the  minimum  size  for  the 
enumeration  type  (see  section  F  4.1  for  details.)  When  such  a  size  is  used  and 
none  of  the  internal  codes  are  negative  integers,  the  internal  representation 
of  the  Ada  type  will  be  unsigned  and  will  conform  with  the  HP  Pascal 
representation. 
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If  such  a  size  specification  representation  clause  is  not  used,  it  is  still  possible 
to  pass  a  simple  variable  or  expression  of  such  a  type  to  HP  Pascal,  by  value 
or  reference,  or  to  return  one  from  HP  Pascal.  Although  the  Ada  enumeration 
object  is  stored  in  a  larger  container  than  HP  Pascal  expects,  the  valid  values 
are  actually  all  stored  within  the  part  of  the  container  that  HP  Pascal  will 
access. 

However,  unless  a  size  specification  representation  clause  is  used,  there  will  be 
difficulty  passing  arrays  of  Ada  enumeration  values  of  such  types  or  passing 
records  containing  fields  of  such  types.  HP  Pascal  will  not  properly  access  the 
correct  elements  of  such  arrays  or  fields  of  such  records  because  it  will  assume 
the  enumeration  values  to  be  smaller  than  they  actually  are  and  therefore  will 
compute  their  location  incorrectly. 

If  a  representation  specification  is  applied  to  the  Ada  enumeration  type  to 
alter  the  internal  value  of  any  enumeration  elements,  care  must  be  taken 
that  the  values  are  within  the  HP  Pascal  enumeration  type  to  which  the  Ada 
enumeration  value  is  being  passed. 

Ada  supports  the  return  of  a  function  result  that  is  an  enumeration  type  from 
an  external  interfaced  function  subprogram  written  in  HP  Pascal. 
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F  11.5.1.3  Boolean  Types  and  HP  Pascal  Subprograms 

See  section  “F  11.1.1.3  Boolean  Types”  for  details. 


.F  11.5.1.4  Character  Types  and  HP  Pascal  Subprograms 

See  section  “F  11,1.1.4  Character  Types”  for  details. 

Values  of  the  Ada  predefined  character  type  might  be  treated  as  the  type  CHAR 
in  HP  Pascal  external  interfaced  subprograms. 
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F  11.5.1.5  Real  Types  and  HP  Pascal  Subprograms 

The  following  subsections  discuss  passing  Ada  real  types  to  interfaced 
HP  Pascal  subprograms. 


Fixed  Point  Types 

Ada  fixed  point  types  are  not  supported  as  parameters  or  as  results  of  external 
subprograms.  Ada  fi.xed  point  types  cannot  be  returned  as  function  results 
from  interfaced  subprograms  written  in  HP  Pascal. 


Floating  Point  Types 

See  section  “F  11.1.1.5  Real  Types”  for  details. 

Ada  FLOAT  values  correspond  to  HP  Pascal  real  values.  Ada  L0NG_FL0AT  values 
correspond  to  HP  Pascal  longreal  values. 


F  11.5.2  Access  Types  and  HP  Pascal  Subprograms 

See  section  “F  11.1.2  Access  Types”  for  details. 

Ada  access  values  can  be  treated  as  pointer  values  in  HP  Pascal.  The  Ada 
heap  allocation  and  the  HP  Pascal  heap  allocation  are  completely  separate. 
There  must  be  no  explicit  deallocation  of  an  access  or  pointer  object  in  one 
language  of  an  object  allocated  in  the  other  language. 
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F  11.5.3  Array  Types  and  HP  Pascal  Subprograms 

See  section  “F  11.1.3  Array  Types”  for  details. 

Arrays  with  components  with  the  same  representation  have  the  same 
representation  in  Ada  and  HP  Pascal. 

Arrays  cannot  be  passed  by  value  from  Ada  to  HP  Pascal.  An  Ada  array  can 
only  be  passed  to  a  VAR  parameter  in  an  HP  Pascal  subprogram. 

Array  types  cannot  be  returned  as  function  results  from  external  interfaced 
subprograms  written  in  HP  Pascal. 

Pascal  conformant  array  parameters  passed  by  reference  (VAR)  can  be  passed 
from  Ada  to  Pascal.  To  pass  such  parameters,  additional  implicit  parameters 
expected  by  Pascal  must  be  added  in  the  Ada  declaration  of  the  Pascal 
procedure  or  function.  For  each  dimension,  except  the  last  dimension,  these 
additional  parameters  are  the  bounds  of  the  array  followed  by  the  size  of  the 
array  elements  in  bytes  and  they  must  immediately  follow  the  conformant  array 
parameter  or  parameters.  The  bounds  and  element  size  parameters  must  be 
declared  as  in  parameters  of  an  integer  or  enumeration  type. 

When  more  than  one  conformant  array  parameter  is  declared  in  a 
comma-separated  formal  parameter  list  in  a  Pascal  procedure  or  function 
heading,  all  the  actual  parameters  passed  to  the  formals  in  that  list  must  have 
the  same  number  of  dimensions  and  the  same  lower  and  upper  index  bound  in 
each  dimension.  Therefore,  only  one  set  of  implicit  bound  parameters  is  needed 
for  the  two  formal  parameters  A  and  B  in  the  following  example  (no  element 
size  is  passed  to  A  and  B  because  they  have  only  one  dimension).  The  actual 
parameters  passed  to  the  formal  A  and  B  parameters  must  have  the  same  index 
bounds. 
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Note  that  two  sets  of  implicit  bound  parameters  and  one  element  size 
parameter  are  needed  for  the  two-dimensional  conformant  array  formal 
parameter  C  (one  set  of  bounds  for  each  dimension  and  an  element  size  for  the 
second  dimension).  If  there  are  additional  two-dimensional  conformant  array 
parameters,  and  they  are  all  declared  in  the  same  comma-separated  parameter 
list  in  Pascal  (with  the  C  parameter),  only  the  two  sets  of  implicit  bound 
parameters  and  the  one  element  size  parameter  is  required  for  the  entire  list. 
For  example,  if  the  Pascal  function  heading  is 

function  VectorThing 

(VAR  a.b:  ARRAY  [i-.j:  INTEGER]  of  INTEGER: 

VAR  c  ;  ARRAY  [p..q:  INTEGER]  of  ARRAY  [r..s:  INTEGER] 
of  INTEGER)  :  INTEGER; 
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The  Ada  declaration  to  call  such  a  Pascal  function  follows; 
with  SYSTEM: 

procedure  PASCAL.CONFORM.FUNC  is 

type  VECTOR  is  array  (INTEGER  range  -492 . . +500) 

of  INTEGER  range  -100.. +100; 

type  VECT0R2  is  array  (INTEGER  range  1..10)  of  VECTOR; 

function  VECTORTHING  (A.  B:  VECTOR; 

I.  J;  INTEGER 
C;  VECT0R2: 

P,  Q:  INTEGER: 

R,  S:  INTEGER: 

ELSIZE:  INTEGER)  return  INTEGER; 
pragma  INTERFACE  (PASCAL,  VECTORTHING); 

—  An  appropriate  pragma  INTERFACE.NAME  is  needed  here 

—  to  properly  access  the  Pascal  function  because  the 

—  actual  function  name  depends  on  the  Pascal  module 
--  in  which  the  function  appears. 

VECTOR.SIZE  ;  constant  INTEGER 

:=  VECTOR ’SIZE  /  SYSTEM. STORAGE.UNIT; 

W,  V:  VECTOR; 

X  :  VECT0R2; 

I  :  INTEGER; 

begin  —  PASCAL.CONFORM.FUNC 
I  :=  VECTORTHING  (W.  V, 

VECTOR ’FIRST,  VECTOR ’LAST, 

X, 

VECT0R2’ FIRST,  VECT0R2 ’LAST , 

VECTOR ’FIRST,  VECTOR ’LAST, 
VECTOR.SIZE) : 
end  PASCAL.CONFORM.FUNC; 
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F  11.5.4  Siring  Types  and  HP  Pascal  Subprograms 

See  section  F  11.1.3  for  details. 

Passing  variable  length  strings  between  Ada  and  HP  Pascal  is  supported 
with  some  restrictions.  Strings  cannot  be  passed  by  value  from  Ada  to  HP 
Pascal.  An  Ada  string  can  only  be  passed  to  a  VAR  parameter  in  an  HP  Pascal 
subprogram. 

String  types  cannot  be  returned  as  function  results  from  external  HP  Paiscal 
subprograms. 

Although  there  is  a  difference  in  the  implementation  of  the  type  STRING  in  the 
two  languages,  with  suitable  declarations  you  can  create  compatible  types  to 
allow  the  passing  of  both  Ada  strings  and  HP  Pascal  strings.  An  Ada  string 
corresponds  essentially  to  a  packed  array  of  characters  in  Pascal.  However, 
the  Ada  string  type  must  be  one  character  longer  than  the  corresponding 
string  type  in  the  HP  Pascal  procedure  or  function.  HP  Pascal  adds  such  an 
implicit  extra  byte  to  its  own  packed  arrays  of  characters  and  expects  to  be 
able  to  utilize  this  extra  byte  during  some  string  operations.  The  following 
example  illustrates  the  declaration  of  compatible  types  for  passing  an  Ada 
string  between  an  Ada  program  and  an  HP  Pascal  subprogram. 

HP  Pascal  subprogram: 

(*  passing  an  Ada  STRING  type  to  an  HP  Pascal  routine  *) 

module  p; 

export 

type  stringSO  =  packed  array  [1..80]  of  char; 
procedure  exl  (  var  s  :  stringSO;  len  :  integer  ); 
implement 

procedure  exl; 
begin 

...  (*  update/use  the  Ada  string  as  a  PAG  ♦) 
end; 
end. 
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Ada  program: 

—  Ada  calling  HP  Pascal  procedure  with  Ada  STRING 
procedxire  AP_1  is 

—  Define  Ada  string  corresponding  to 
—  HP  Pascal  packed  array  of  char 

subtype  STRING80  is  STRING  (  1..81  );  —  80+1  for  HP  Pascal 

—  Ada  definition  of  HP  Pascal  procedure  to  be  called, 

—  with  an  Ada  STRING  parameter,  passed  by  reference, 
procedure  EXl  (S  :  in  out  STRING80; 

LEN  ;  INTEGER  ); 

pragma  INTERFACE  (PASCAL,  EXl); 
pragma  INTERFACE.NAME  (EXl,  "exl"); 

S  :  STRING80; 

begin  —  AP.l 

S(1..26)  "Ada  to  HP  Pascal  Interface"; 

EXl  (S,  26);  —  Call  the  HP  Pascal  subprogram 

end  AP.l; 
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An  HP  Pascal  STRING  type  corresponds  to  a  record  in  Ada  that  contains 
two  fields:  a  32-bit  integer  field  containing  the  string  length  and  an  Ada 
STRING  field  containing  the  string  value.  The  following  example  illustrates  the 
declaration  of  compatible  types  for  passing  an  HP  Pascal  string  between  an 
Ada  program  and  a  Pascal  subprogram. 

Pascal  subprogram: 

(♦  passing  an  HP  Pascal  STRING  type  from  Ada  to  *) 

(*  an  HP  Pascal  routine  *) 

module  p; 

export 

type  stringSO  =  string [80]; 
procedure  ex2  (  var  s  :  stringSO  ) ; 
implement 

procedure  ex2 ; 
var 

str  :  stringSO  ; 
begin 

. . .  — update/use  the  HP  Pascal  string 
ena; 
end . 
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Ada  program: 


—  Ada  calling  HP  Pascal  procedure  using  a  HP  Pascal  string [80] 
procedure  AP_2  is 

—  Define  an  Ada  record  that  will  correspond  exactly 

—  with  the  HP  Pascal  type:  string [80] 

type  PASCAL_STRING80  is 
record 

LEN  :  INTEGER; 

S  :  STRING  (  1..81  );  —  80+1  for  HP  Pascal 
end  record; 

—  Here  we  use  a  record  representation  clause  to 

—  force  the  compiler  to  layout  the  record  in 

—  the  correct  manner  for  HP  Pascal 

for  PASCAL.STRING80  use 
record 

LEN  at  0  range  0  ..  31; 

S  at  1  range  0  ..  81*8;  --  80+1  for  HP  Pascal 
end  record; 

—  The  Ada  definition  of  the  HP  Pascal  procedure  to  be 

—  called,  with  an  HP  Pascal  STRING  parameter,  passed 

—  by  reference. 

procedure  EX2  (S  :  in  out  PASCAL_STRING80) ; 
pragma  INTERFACE  (PASCAL,  EX2) ; 
pragma  INTERFACE.NAME  (EX2,  "ex2"); 

PS  ;  PASCAL_STRING80; 

begin  —  AP_2 

—  assign  value  field 

PS.S(l..26)  :=  "Ada  to  HP  Pascal  Interface"; 
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PS.LEN  :*  26; 
EX2  (  PS  ); 


—  set  string  length  field 

—  call  the  HP  Pascal  subprogram 


end  AP_2; 


F  11.5.5  Record  Types  and  HP  Pascal  Subprograms 

See  section  “F  11.1.4  Record  Types”  for  details. 

Records  cannot  be  passed  by  value  from  Ada  to  HP  Pascal.  An  Ada  record  can 
only  be  passed  to  a  VAR  parameter  in  an  HP  Pciscal  subprogram. 

Record  types  cannot  be  returned  as  function  results  from  external  HP  Pascal 
subprograms. 
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F  11.6  Summary 

Table  11-6  shows  how  various  Ada  types  are  passed  to  subprograms. 


Table  11-6. 

Modes  for  Passing  Parameters  to  Interfaced  Subprograms 


Ada  Type 

Mode 

Passed  By 

ACCESS, 

SCALAR 

-IHTEGER 

-ENUMERATION 

-BOOLEAN 

-CHARACTER 

-REAL 

in 

value 

ARRAY, 

RECORD 

in 

reference 

all  types  except  TASK 
and  FIXED  POINT 

in  out 

reference 

all  types  except  TASK 
and  FIXED  POINT 

out 

reference 

TASK 

FIXED  POINT 

N/A 

not  passed 
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Table  11-7  summarizes  general  information  presented  in  section  “F  11.1 
General  Considerations  in  Passing  Ada  Types”. 


Table  11-7. 

Types  Returned  as  External  Function  Subprogram  Results 


Ada  Type 

Precision 
Architecture 
RISC  Assembly 
Language 

HP  C 

HP  FORTRAN 

HP  Pascal 

IHTEGER 

allowed 

allowed 

allowed 

allowed 

ENUMERATlOir 

allowed 

allowed 

not  allowed  (1) 

allowed 

CHARACTER 

allowed 

allowed 

not  allowed 

allowed 

BOOLEAN 

allowed 

allowed 

allowed 

allowed 

FLOAT 

allowed 

allowed  (2) 

allowed 

allowed 

FIXED  POINT 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

ACCESS 

allowed 

allowed 

not  allowed  (1) 

allowed 

ARRAY 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

STRING 

not  allowed 

not  allowed 

not  allowed  (3) 

not  allowed 

RECORD 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

TAS 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

Notes  for  Table  11-7: 

(1)  ss  as  an  integer  equivalent. 

(2)  Some  restrictions  apply  to  Ada  FLOAT  types  (in  passing  to  HP  C 
subprograms). 

(3)  Accessible  if  function  called  as  a  procedure  with  ‘‘extra”  parameters. 

Table  11-8  summarizes  information  presented  in  sections  F  11.2  through  F  11.5. 
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Table  11*8.  Parameter  Passing  in  the  Ada  Implementation 


Ada  Type 

Precision 
Architecture 
RISC  Assembly 
Language 

HP  C 

HP  FORTRAN 

HP  Pascal 

INTEGER 

allowed 

allowed 

allowed 

allowed 

ENUMERATION 

allowed 

allowed 

not  allowed  (1) 

allowed 

CHARACTER 

allowed 

allowed 

not  allowed  (2) 

allowed 

BOOLEAN 

allowed 

allowed 

not  allowed  (1) 

allowed 

FLOAT 

allowed 

allowed 

allowed 

allowed 

FIXED  POINT 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

ACCESS 

allowed 

allowed 

not  allowed 

allowed 

ARRAY  (3) 

allowed 

allowed 

allowed  (4) 

allowed  (8) 

STRING 

allowed 

allowed  (5) 

allowed  (6) 

not  allowed  (7) 

RECORD 

allowed 

allowed 

allowed 

allowed 

TASK 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

Notes  for  Table  11-8: 

(1)  Can  be  passed  as  an  equivalent  integer  value. 

(2)  Must  be  passed  as  a  STRING. 

(3)  Using  only  arrays  of  compatible  component  types. 

(4)  See  warning  on  layout  of  elements. 

(5)  Special  handling  of  null  terminator  character  is  required. 

(6)  Requires  that  the  length  also  be  passed. 

(7)  Ada  strings  can  be  passed  to  a  Pascal  PAC  (Packed  Array  of  Characters) 

(8)  Conformant  arrays. require  that  “e.xtra"  parameters  be  paissed. 
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F  11.7  Potential  Problems  Using  Interfaced  Subprograms 

F  11.7.1.  Signals  and  interfaced  Subprograms 

The  Ada  run-time  on  the  HP  9000  Series  600,  700,  and  800  computers 
uses  signals  in  a  manner  that  generally  does  not  interfere  with  interfaced 
subprograms.  However,  some  HP-UX  routines  are  interruptible  by  signals. 
These  routines,  if  called  from  within  interfaced  external  subprograms,  may 
create  problems.  You  need  to  be  aware  of  these  potential  problems  when 
writing  external  interfaced  subprograms  in  other  languages  that  will  be  called 
from  within  an  Ada  main  subprogram.  See  sigvector(2)  in  the  HP-UX 
Reference  for  a  complete  explanation  of  interpretability  of  operating  system 
routines. 

The  following  should  be  taken  into  consideration: 

■  SIGALRM  is  sent  when  a  delay  statement  reaches  the  end  of  the  specified 
interval. 

■  One  of  SIGALRM,  SIGVTALRM  (the  default),  or  SIGPROF  is  sent  periodically 
when  time-slicing  is  enabled  in  a  tasking  program. 

■  Interruptible  HP-UX  routines  (see  sigvector(2))  may  need  to  be 
protected  from  interruption  by  the  signals  used  by  the  Ada  run-time 
system.  The  SYSTEM.ENVIRONMENT  routines  SUSPEND.ADA.TASKING  and 
RESUME.ADA.TASKING  can  be  used  to  implement  this  protection.  As 

an  alternative,  the  knowledgeable  user  can  use  the  sigsetinask(2)  or 
sigblock(2)  mechanism  to  implement  the  same  protection. 

■  If  a  signal  is  received  while  it  is  blocked,  one  instance  of  the  signal  is 
guaranteed  to  remain  pending  and  will  be  honored  when  the  signal  is 
unblocked.  Any  additional  instances  of  the  signal  will  be  lost. 

■  Any  signals  blocked  in  interfaced  code  should  be  unblocked  before  leaving  the 
interfaced  code. 
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The  alarm  signals  sent  by  delay  statements  and  sent  to  implement  time-slicing 
(noted  above)  are  the  most  likely  signals  to  cause  problems  with  interfaced 
subprograms.  These  signals  are  aisynchronous;  that  is,  they  can  occur  at  any 
time  and  are  not  caused  by  the  code  that  is  executing  at  the  time  they  occur. 
In  addition,  SIGALRM  and  SIGPROF  (but  not  SIGVTALRM)  can  interrupt  HP-UX 
routines  that  are  sensitive  to  being  interrupted  by  signals. 

Problems  can  arise  if  an  interfaced  subprogram  initiates  a  “slow”  operating 
system  function  that  can  be  interrupted  by  a  signal  (for  example,  a  read (2) 
call  on  a  terminal  device  or  a  wait (2)  call  that  waits  for  a  child  process  to 
complete).  Problems  can  also  arise  if  an  interfaced  subprogram  can  be  called 
by  more  than  one  task  and  is  not  reentrant.  If  an  Ada  reserved  signal  occurs 
during  such  an  operation  or  non-reentrant  region,  the  program  may  function 
erroneously. 

For  example,  an  Ada  program  that  uses  delay  statements  and  tasking 
constructs  causes  the  generation  of  SIGALRM  and  optionally  either  SIGVTALRM 
or  SIGPROF.  If  an  intefaced  subprogram  needs  to  perform  a  potentially 
interruptible  system  call  or  if  the  interfaced  subprogram  can  be  called  from 
more  than  one  task  and  is  not  reentrant,  you  can  protect  the  interfaced 
subprogram  by  blocking  the  potentially  interrupting  time  signals  around  the 
system  call  or  non-reentrant  region.  If  one  of  these  timer  signals  does  occur 
while  blocked,  signifying  either  the  end  of  a  delay  period  or  the  need  to 
reschedule  due  to  time-slice  expiration,  that  signal  is  not  lost;  it  is  effectively 
deferred  until  it  is  later  unblocked. 
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Assuming  a  tasking  program,  which  contains  one  or  more  delay  statements, 
with  time-slicing  enabled  using  the  default  time-slicing  signal  (SIGVTALRM),  the 
following  example  shows  a  protected  read  (2)  call  in  the  C  language: 


tinclude  <signal.h> 
void  interface.routO ; 

long  mask; 


/*  Add  SIGALRM  and  SIGVTALRM  to  the  list  of  currently 
blocked  signals  (see  sigblock(2)) .  */ 

mask  =  sigblock  (sigmask  (SIGALRM)  I  sigmask  (SIGVTALRM)); 

read  (...);  /♦or  non-reentrant  region  */ 

/*  restore  old  mask  so  Ada  rim-time  can  function  */ 
sigsetmask  (mask) ; 
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If  any  Ada  reserved  signal  other  than  SIGALRM  or  the  alarm  signal  (if  any) 
being  used  for  time-slicing  is  to  be  similarly  blocked,  SIGALRM  and  the  alarm 
signal  used  for  time-slicing  must  already  be  blocked  or  must  be  blocked  at  the 
same  time  as  the  other  signal  or  signals. 

Any  Ada  reserved  signal  blocked  in  interfaced  code  should  be  unblocked  before 
leaving  that  code,  or  as  soon  as  possible  thereafter,  to  avoid  unnecessarily 
stalling  the  Ada  run-time  executive.  Failure  to  follow  these  guidelines  will 
cause  improper  delay  or  tasking  operation. 


An  alternative  and  preferred  method  of  protecting  interfaced  code  from  signals 
is  described  in  the  Ada  User’s  Guide  in  the  section  on  “Execution-Time 
Topics.”  The  two  procedures  SUSPEND_ADA_TASKING  and  RESUME.ADA.TASKING 
from  the  package  SYSTEM.ENVIRONMENT  supplied  by  Hewlett-Packard  can  be 
used  within  an  Ada  program  to  surround  a  critical  section  of  Ada  code  or  a  call 
to  external  interfaced  subprogram  code  with  a  critical  section. 


F  11.7.2  Files  Opened  by  Ada  and  Interfaced  Subprograms 

An  interfaced  subprogram  should  not  attempt  to  perform  1/0  operations 
on  files  opened  by  Ada.  Your  program  should  not  use  HP-UX  I/O  utilities 
intermixed  with  Ada  I/O  routines  on  the  same  file.  If  it  is  necessary  to  perform 
I/O  operations  in  interfaced  subprograms  using  the  HP-UX  utilities,  open  and 
close  those  files  with  HP-UX  utilities. 
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F  12.  Interrupt  Entries 

This  chapter  describes  interrupt  entry  processing. 


F  12.1  Introduction 

The  Ada  compiler  supports  a  limited  form  of  interrupt  entries  as  defined  by 

the  Ada  RM,  section  13.5.1.  In  addition,  the  compiler  provides  the  following 

features: 

■  Interrupt  entries  are  associated  with  HP-UX  signals,  but  are  not  directly 
invoked  by  an  HP-UX  signal.  Instead,  the  interrupt  entry  is  called  from 
an  Ada  signal  handling  procedure.  An  Ada  signal  handling  procedure  can 
be  associated  with  one  or  more  HP-UX  signals.  If  an  Ada  signal  handler 
wants  to  call  an  interrupt  entry,  it  can  only  call  the  interrupt  entry  that  is 
associated  with  the  same  HP-UX  signal  that  caused  the  Ada  signal  handler 
itself  to  be  invoked. 

■  Interrupt  entries  associated  with  HP-UX  signals  can  have  parameters. 

■  If  the  interrupt  entry  call  cannot  be  processed  immediately  by  the  server 
task,  the  interrupt  entry  parameters  are  buffered  so  that  the  interrupt  is  not 
lost  and  the  entry  is  processed  as  soon  as  conditions  permit. 

■  All  signals  except  the  ones  reserved  by  the  Ada  runtime  and  the  HP-UX 
system  can  be  handled  with  up  to  seven  different  priorities.  The  interrupt 
entry  mechanism  will  not  prohibit  the  use  of  signals  reserved  by  the  Ada 
runtime  or  by  HP-UX.  but  using  such  signals  for  interrupt  entries  will  cause 
unpredictable  program  behavior. 
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F  12.2  immediate  Processing 

If  an  Ada  handler  has  been  associated  with  an  HP-UX  signal,  when  that 
signal  occurs,  an  internal  signal  handler  installed  by  the  runtime  system 
is  entered.  That  internal  handler  then  calls  the  user-defined  Ada  handler. 

One  parameter  of  type  SYSTEM .  ADDRESS  is  passed  to  the  user  handler;  the 
parameter  is  the  “signal  number”  that  caused  it  to  be  invoked  (a  function  is 
provided  to  convert  the  integer  representation  of  a  “signal  number”  into  an 
object  of  type  SYSTEM. ADDRESS).  The  Ada  handler  can  make  an  entry  call  to 
a  task  entry  associated  with  the  particular  signal  and/or  it  can  update  global 
state  information  (for  example,  variables)  that  is  meaningful  to  the  program. 

It  should  then  return,  giving  control  to  the  internal  handler  in  the  runtime 
system. 

If  the  Ada  handler  makes  an  entry  call  to  an  entry  previously  declared  with 
a  representation  clause  as  an  interrupt  entry,  the  rendezvous  does  not  occur 
immediately.  The  kernel  saves  the  parameters  passed  by  the  signal  handler  in  a 
buffer  taken  from  a  pool  of  free  buffers  and  links  the  buffer  to  the  entry  queue 
for  the  interrupt.  The  actual  rendezvous  will  take  place  in  deferred  processing 
(see  section  “F  12.3  Deferred  Processing”).  The  pool  of  free  buffers  is  allocated 
once  at  the  program  startup  by  calling  INIT.INTERRUPT.MANAGER  with  the 
number  of  buffers  specified  (see  section  “F  12.5  Initializing  the  Interrupt  Entry 
Mechanism”). 


Note  The  .4 da  handler  must  not  call  any  Ada  Runtime  System 

routines  and  must  be  compiled  with  checks  off.  See  sections 
“F  12.6  Associating  an  Ada  Handler  with  an  HP-UX  Signal” 
and  “F  12.6.1  Determining  If  Your  Ada  Handier  Makes  Ada 
Runtime  C2Jls”  for  details. 
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F  12.3  Deferred  Processing 

The  deferred  processing  step  is  the  execution  of  the  accept  statement  for  the 
interrupt  entry.  It  is  performed  with  signals  enabled  and  with  an  Ada  task 
priority  specified  by  the  user  (but  higher  than  any  software  priority  as  required 
by  the  Ada  RM,  section  13.5.1.2).  The  accept  statement  has  access  to  the  IN 
parameters  provided  by  the  Ada  handler  when  the  Ada  handler  made  the  entry 
call.  There  aje  no  limitations  on  the  code  of  the  accept  statement;  run-time 
calls  are  allowed. 

The  connection  between  the  immediate  and  deferred  processing  is  made  by 
the  Ada  runtime.  At  the  end  of  the  immediate  processing  step,  when  the 
Ada  handler  returns  control  to  the  internal  handler  in  the  Ada  runtime,  Ada 
runtime  checks  to  see  if  any  immediate  processing  steps  remain  active  (that  is, 
an  Ada  signal  handler  has  been  called  in  response  to  a  signal  but  has  not  yet 
returned).  If  any  immediate  processing  steps  remain  active,  the  .4da  runtime 
simply  returns  control  to  the  interrupted  context,  which  will  be  one  of  the 
currently  active  Ada  signal  handlers. 

If  no  immediate  processing  steps  remain  active  (that  is,  the  Ada  signal  hai  dler 
that  is  currently  returning  control  to  the  Ada  runtime  is  the  only  currentl’ 
active  Ada  signal  handler),  the  Ada  runtime  identifies  all  of  the  tasks  and 
entries  that  immediate  processing  steps  have  requested  be  called.  There  may 
be  more  than  one  interrupt  entry  call  pending  because  multiple  different 
signals  may  have  been  received,  causing  multiple  Ada  signal  handlers  to  be 
simultaneously  active.  Onlv  when  the  last  active  Ada  signal  handier  returns 
control  to  the  Ada  runtime  will  the  pending  tasks  or  entries  be  considered  as 
callable.  The  Ac  a  runtime  will  determine  for  each  pending  interrupt  entry 
.call  whether  the  accept  statement  can  be  executed  immediately.  If  so.  the 
current  task  is  preempted  unless  it  is  of  equal  or  higher  priority  than  any  of  the 
pending  interrupt  entry  calls  (for  example,  the  current  task  is  itself  executing 
an  accept  statement  for  a  higher  priority  interrupt).  Pending  interrupt  entry 
calls  for  which  the  accept  can  be  e.\ecuted,  but  which  are  of  a  lower  priority 
than  the  currently  running  task,  will  be  made  as  their  priority  permits  (note 
that  call.s  to  interrupt  entries  with  identical  priorities  may  occur  in  an  arbitrary 
order). 

If  the  accept  statement  cannot  be  executed  immediately,  the  rendezvous  will 
take  place  according  to  normal  .4da  semantics  when  the  server  task  executes  an 
accept  or  select  statement  for  the  given  entry. 
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There  are  no  restrictions  on  the  number  of  interrupt  entries  one  task  can  use, 
nor  on  the  number  of  tasks  that  can  use  interrupt  entries.  The  only  restriction 
is  that  oivly  one  entry  may  be  associated  with  a  given  HP-UX  signal  aind  that 
signals  reserved  by  the  Ada  runtime  may  not  be  associated  with  an  interrupt 
entry. 

The  buffering  of  the  interrupt  entry  call  from  the  Ada  handler  to  the  interrupt 
entry  attempts  to  ensure  that  no  signal  will  be  lost.  It  is  important  that  the 
average  execution  time  of  the  interrupt  entry  be  smaller  than  the  signal  rate 
for  the  associated  signal,  otherwise  the  pool  of  buffers  to  hold  interrupt  entry 
parameters  will  be  quickly  exhausted.  Each  buffer  is  released  immediately 
before  execution  oi  the  accept  body  for  the  interrupt  entry  after  the  parameters 
have  been  copied  to  the  stack  of  the  acceptor  task.  It  is  also  important  that 
the  execution  time  of  the  Ada  signal  handlers  be  minimized  as  the  deferred 
processing  step  is  not  performed  when  any  Ada  signal  handler  remains  active. 


F  12.4  Handling  an  Interrupt  Entirely  in  the  Immediate 
Processing  Step 

Calling  an  interrupt  entry  in  response  to  a  signal  is  optional.  Interrupts  can 
be  handled  in  a  sequential  program  that  has  no  tasks  to  call  or  in  a  tasking 
program  without  calling  an  interrupt  entry  if  the  Ada  handler  performs  all  the 
required  processing.  This  can  improve  performance  because  the  overhead  of 
task  switching  is  avoided.  However,  because  the  Ada  handler  cannot  make  Ada 
run-time  calls  and  must  be  compiled  with  checks  off  (usi.ng  the  -R  option),  the 
amount  of  processing  that  an  Ada  handler  can  do  is  limited.  In  addition,  if 
the  Ada  haildler  does  all  the  processing,  the  Ada  program  must  generally  poll 
global  state  information  to  determine  that  the  signal  has  been  received. 
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F  12.5  Initializing  the  interrupt  Entry  Mechanism 

The  compiler  provides  the  package  INTERRUPT.MANAGER  to  support  interrupt 
entries.  This  package  is  in  the  predefined  library. 

To  use  interrupt  entries,  you  must  initialize  the  interrupt  manager  by  calling 
this  procedure: 

procedure  INIT.INTERRUPT.MANAGER 

(NUMBER.QF.BUFFERS  ;  in  BUFFER.NUMBER; 
MAX.PARAM_AREA_SIZE  :  in  BYTE.SIZE; 
INTERRUPT.STACK.SIZE  :  in  BYTE.SIZE  :=  2048); 

This  procedure  allocates  the  given  number  of  buffers  to  hold  parameters  of 
interrupt  entries  that  cannot  be  processed  immediately  and  allocates  a  signal 
stack  of  the  given  size.  The  size  of  each  buffer  is  the  maximum  parameter  area 
size  specified  to  the  call,  plus  a  fi.xed  overhead  of  28  bytes  used  by  the  Ada 
runtime.  If  the  given  signal  stack  size  is  zero,  all  signeds  are  handled  on  the 
current  stack;  therefore,  all  stacks  must  have  sufficient  buffer  space.  Using  an 
interrupt  stack  allows  better  usage  of  available  memory. 

The  MAX.PARAM.AREA.SIZE  parameter  must  be  the  size,  in  storage  units,  of 
the  largest  parameter  block  required  by  an  interrupt  entry  call.  A  parameter 
block  is  an  area  of  memory  in  which  the  generated  code  for  a  task  entry  call 
temporarily  stores  the  actual  parameters  of  the  task  entry  call.  The  address  of 
the  parameter  block  is  passed  to  the  Ada  run-time  routine  ENTRY_CALL  which 
makes  the  parameters  available  to  the  called  task  entry  when  the  rendezvous 
actually  occurs.  In  the  case  of  an  interrupt  entry,  the  Ada  runtime  copies  the 
parameter  block  into  one  of  the  buffers  tillocated  by  INIT.INTERRUPT.MANAGER 
until  the  deferred  processing  step  is  reached. 
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The  parameter  block  sizes  for  the  task  entries  to  be  called  by  Ada  signal 
handling  procedures  can  be  obtained  by  compiling  the  specifications  of  the  task 
for  such  entries  with  the  -H  option.  An  informational  message  is  produced 
indicating  the  parameter  block  size  for  each  task  entry  specification  that  has 
an  address  clause,  indicating  it  is  a  candidate  for  calling  from  an  Ada  signal 
handling  procedure. 

The  procedure  INIT_INTERRUPT_MANAGER  must  be  called  at  program  startup 
before  any  call  is  made  to  an  interrupt  entry  from  an  Ada  signal  handler. 

Entry  calls  will  be  lost  if  the  number  of  buffers  is  insufficient.  The  required 
number  of  buffers  depends  on  the  frequency  of  signals.  A  zero  number  of 
buffers  can  be  used  when  the  signal  handler  only  buffers  information  and  never 
calls  an  interrupt  entry. 

This  procedure  raises  STQRAGE.ERRQR  if  there  is  not  enough  memory  to  allocate 
the  required  buffers  and  the  interrupt  stack. 
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F  12.6  Associating  an  Ada  Handler  with  an  HP-UX  Signal 

You  can  install  a  signal  handler  by  calling  the  following  procedure: 

procedure  INSTALL.HANDLER 

(HANDLER. ADDRESS  :  in  SYSTEM . ADDRESS ; 

SIG  :  in  SYSTEM . ADDRESS ; 

PRIORITY  :  in  INTERRUPT.PRIORITY 

INTERRUPT.PRIORITY ’FIRST; 
ORIGINAL.HANDLER  :  in  ACTION  :*  REPLACED); 

This  procedure  installs  an  Ada  routine,  specified  via  HANDLER.ADDRESS,  as  the 
Ada  handler  for  the  specified  HP-UX  signal  (SIG)  after  saving  the  address 
of  the  original  handler.  If  the  Ada  handler  calls  an  interrupt  task  entry,  the 
signal  number  passed  to  this  procedure  as  SIG  must  be  the  same  as  the  one 
specified  in  the  interrupt  entry  address  clause  (see  “F  12.10  Address  Clauses 
for  Entries”)  for  that  task  entry.  The  PRIORITY  parameter  specifies  the  priority 
of  the  entry  call  to  be  made  by  the  handler  (all  accept  statements  will  run 
with  this  priority  unless  they  are  themselves  within  an  accept  statement 
executed  at  higher  priority.)  The  ORIGINAL.HANDLER  parameter  controls 
whether  the  current  signal  handler,  the  one  the  Ada  handler  is  replacing,  is  to 
be  called  before  (FIRST)  or  after  (LAST)  the  new  Ada  handler  or  not  called  at 
all  (REPLACED). 

The  INSTALL.HANDLER  procedure  must  be  called  from  a  scope  that  encloses  the 
declaration  of  the  Ada  procedure  that  is  being  installed  as  the  Ada  handler. 

A  convenient  technique  is  to  declare  the  Ada  handler  procedure  immediately 
within  a  library  level  package  and  place  the  call  to  INSTALL.HANDLER  in 
the  package  body  block.  INSTALL.HANDLER  will  not  detect  any  error  if  this 
restriction  is  violated;  however,  unexpected  program  behavior  or  program 
failure  may  occur  when  an  incorrectly  installed  Ada  handler  is  invoked. 

The  Ada  handler  must  be  a  procedure  with  one  parameter  of  type 
SYSTEM .  ADDRESS  and  w'ithout  inner  units.  The  procedure  can  only  reference 
local  or  global  objects,  excluding  objects  of  an  enclosing  frame,  and  must  be 
compiled  with  checks  off  (using  the  -R  option).  If  an  entry  call  is  made  in  an 
Ada  handler,  the  task  the  entry  belongs  to  must  be  a  global  object. 

The  Ada  handler  must  not  call  any  Ada  Runtime  System  routines  (either 
explicitly  or  implicitly)  other  than  simple  entry  calls  to  interrupt  entries 
because  some  of  the  ,4da  run-time  routines  update  critical  run-time  data 
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structures  and  must  not  be  reentered  during  such  updates.  Specifically,  neither 
timed  nor  conditional  entry  calls  may  be  made. 

The  Ada  handler  must  not  call  HP-UX  routines  or  other  non- Ada  code,  either 
via  pragma  INTERFACE  or  via  a  binding. 

If  the  Ada  handler  calls  another  Ada  procedure  or  function,  that  procedure  or 
function  must  follow  these  same  constraints. 

For  certain  complex  data  structures,  the  compiler  produces  Type  Support 
Subprograms  (TSS).  These  subprograms  perform  actions  such  as  initializing 
record  fields,  comparing  records,  changing  record  representation,  and  so  on. 

The  compiler  then  adds  implicit  calls  to  these  routines  when  needed.  Some 
calls  to  TSS  routines  are  not  safe  in  Ada  handlers.  If  the  TSS  calls  Ada 
Runtime  System  routines,  that  TSS  should  not  be  called  from  an  Ada  handler. 
To  remove  the  call,  you  have  to  simplify  the  code  so  that  the  action  that  needs 
the  call  is  no  longer  present.  The  -H  option,  if  used  when  compiling  the  Ada 
handler,  causes  an  informational  message  to  be  produced  if  the  generated  code 
contains  a  call  to  one  or  more  TSS  routines.  Additionally,  the  massages  specify 
the  type  that  the  TSS  supports. 

In  general,  the  code  in  an  Ada  handler  should  be  kept  extremely  simple.  It  is 
recommended  to  only  set  a  global  flag  or  make  an  entry  call  to  an  interrupt 
entry  to  actually  do  the  required  processing. 

The  HP-UX  signal  currently  being  handled  is  masked  for  the  duration  of  the 
Ada  handler. 

The  address  of  the  Ada  procedure  to  use  as  the  Ada  handler  can  be  obtained 
by  the  ’ADDRESS  attribute,  which  is  only  valid  after  elaboration  of  the 
procedure  body. 

The  procedure  INSTALL.HANDLER  raises  STORAGE.ERROR  if  MAX.HANDLERS 
handlers  have  already  been  defined. 
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F  12.6.1  Determining  If  Your  Ada  Handler  Makes  Ada  Runtime  Calls 

If  you  are  not  sure  your  Ada  handler  maJces  specific  Ada  Runtime  System 
routine  calls,  you  can  compile  the  Ada  source  file  containing  the  Ada  handler 
with  the  -H  option.  The  -H  option  causes  the  compiler  to  produce  a  warning 
message  each  time  it  generates  code  to  call  an  Ada  Runtime  System  routine. 

If  you  generate  a  complete  compiler  listing  with  the  -B  or  ~L  options,  the 
warnings  appear  in  the  compiler  listing  at  the  appropriate  source  lines.  If  you 
do  not  generate  a  complete  compiler  listing  (with  -B  or  -L  options),  only  the 
source  lines  that  apply  to  the  warning  appear  in  a  listing  with  the  warning. 
Check  the  names  of  the  Ada  Runtime  System  routines  that  appear  in  the 
warning  messages;  if  calls  to  any  of  the  following  Ada  Runtime  System  routines 
appear,  your  Ada  handler  is  “unsafe”. 


ABORT. STMT 
ACCEPT.STMT 
ACTIVATE.COLLECTION 
ALLOC.FIX.SS.ELT 
ALLOC.GO 
ALLDC.LD 

ALLOC.SHALL_FIX.ELT 
ALLOC.TEHP 
ALLOC.TEMP.GH 
ALLOC. VAR.SS.ELT 
CALLABLE 
COMPLETE.MASTER 
COHPLETE.TASK 
COND.CALL 
COND.SELECT 
COUNT 

CREATE.TASK 
CURRENT.OBJECT.OF.TASK.' 
DELAY.STHT 
DESTROY.COLLECTION 


END.ACTIVATION 

EKUMl.PRED 

EKUMl.SUCC 

EKUMI.VAL.TO.POS 

ENUM2_PRED 

ENUM2.SUCC 

ENUM2_VAL.T0_P0S 

EKUH4_PBED 

ENUM4_SUCC 

ENUM4_VAL.T0_P0S 

ENUM.POS 

EHUM.WIDTH 

ENV.TASK.MASTER 

FIXED.FORE 

FIXED.LARGE 

FIXED.MANTISSA 

FREE.FIX.SS.ELT 

FREE.LIST 

FREE.SMALL.FIX.ELT 

FREE.TEHP 


FREE.TEMP.GH 

FREE.VAR.SS.ELT 

INIT.COLLECTION 

INIT.FIX_SS.ELT 

IHIT.HANDLER 

INIT.MASTER 

INIT.SMALL.FIX.ELT 

INIT.VAR.SS.ELT 

INTEGER.IMAGE 

INTEGER.VALUE 

INTEGER.WIDTH 

NULL.B  OD Y_  A  CCEPT.STHT 

SELECT.WITH.TERHINATE 

SIMPLE.SELECT 

SIMPLE.TIHED.SELECT 

TERMINATED 

TERMINATION.COHPLETE 

TIHED.CALL 

TIMED.SELECT 
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A  call  to  ENTRY.CALL  is  safe  as  long  as  it  is  calling  the  task  entry  declared  as 
an  interrupt  entry  for  the  HP-UX  signal  that  caused  the  Ada  signal  handler  to 
be  invoked. 

To  help  you  understand  what  Ada  language  construct  might  cause  such  a  call 
to  be  made,  a  description  of  each  of  the  above  Ada  run-time  routines  is  listed 
in  section  “F  12.13  Ada  Runtime  Routine  Descriptions”. 


12*10  F  12.  Interrupt  Entries 


F  12.7  Disassociating  an  Ada  Handier  from 
an  HP-UX  Signal 

The  Ada  handler  for  a  given  HP-UX  signal  can  be  removed  and  the  original 
HP-UX  signal  handler  (or  signal  behavior)  restored  with  this  procedure 

procedure  REMOVE.HANDLER  (SIG  :  in  SYSTEM. ADDRESS) ; 

This  procedure  only  needs  to  be  called  when  it  is  no  longer  necessary  to 
have  a  handler  for  a  particular  signal.  All  Ada  handlers  are  automaticaUy 
disassociated  from  their  HP-UX  signals  when  the  main  program  terminates. 

The  procedure  REMOVE.HANDLER  raises  PROGRAM.ERROR  if  no  handler  has  been 
installed  for  the  given  signal. 


F  12.8  Determining  How  Many  Handlers  are  Installed 

Use  the  following  procedure  to  determine  how  many  handlers  have  already 
been  installed: 

function  HANDLER.COUNT  return  HANDLER. NUMBER ; 


F  12.9  When  Ada  Signal  Handlers  Will  Not  Be  Called 

When  the  procedure  SYSTEM.ENVIRONMENT. SUSPEND. ADA.TASKING  is  called, 
•the  HP-UX  signals  for  which  Ada  signal  handlers  have  been  installed, 
will  be  masked.  That  is,  the  Ada  signal  handlers  will  not  be  called  if 
one  of  the  signals  should  occur.  At  most  one  instance  of  any  given  signal 
will  be  remembered  while  the  signals  are  masked.  When  the  procedure 
SYSTEM.ENVIRONMENT. RESUME. ADA.TASKING  is  called,  the  signals  for  which  Ada 
signal  handlers  have  been  installed  will  be  unmasked.  Any  signal  that  occurred 
while  the  masking  was  in  effect  will  then  be  delivered  to  the  Ada  program  and 
will  invoke  the  associated  Ada  signal  handlers  (at  most  one  instance  of  any 
such  signal  will  have  been  remembered  while  the  signals  were  masked). 
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Caution  The  Ada  program,  as  well  as  interface  code  called  by  the  Ada 
program,  should  not  unmask  any  of  the  HP-UX  signals  for 
which  Ada  signal  handlers  are  installed  while  Ada  tasking  has 
been  suspended.  Doing  so  will  cause  unpredictable  and  possibly 
erroneous  program  behavior. 


F  12.10  Address  Clauses  for  Entries 

According  to  section  13.5.1  of  the  Ada  RM,  an  address  clause  for  an  interrupt 
entry  has  the  following  form: 

task  INTERRUPT.HANDLER  is 
entry  INTERRUPT( . . .) ; 
for  INTERRUPT  use  at  . . . ; 
end  INTERRUPT.HANDLER; 

An  interrupt  entry  may  have  zero  or  more  parameters  of  mode  IN.  Parameters 
of  mode  IN  OUT  or  OUT  are  not  permitted;  see  section  13.5.1(1)  in  the  Ada 
RM  for  details.  The  expression  in  the  address  clause  must  be  of  type 
SYSTEM .  ADDRESS  and  is  interpreted  as  a  signal  number  by  the  runtime  system. 
A  function  SIGNAL  is  provided  by  the  INTERRUPT.MANAGER  package  to  convert 
an  integer  to  a  SYSTEM. ADDRESS.  Note  that  a  with  statement  for  the  package 
SYSTEM  must  be  specified  for  the  context  in  which  such  an  address  clause 
appears. 
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F  12.11  Example  of  Interrupt  Entries 

The  following  is  a  program  that  uses  interrupt  entries.  The  program  could 
be  written  using  only  Ada  tasking  and  not  using  HP-UX  signals  or  interrupt 
entries;  however,  this  version  provides  a  sample  of  declaring  and  using  the 
interrupt  entry  mechanism.  A  machine  readable  copy  of  this  program  is 
provided  in  $ADA_PATH/sainples/intent/intentexl  .ada  (although  the  text 
and  line  breaks  are  different). 


—  This  program  simulates  an  elevator  which  takes  passengers  from 

—  floor  to  floor. 

—  There  are  three  tasks  :  PASSENGER,  ELEVATOR  and  MANAGER. 

—  The  MANAGER  task  manages  the  elevator  by  determining  the  floor 

—  number  and  the  direction  to  go.  The  PASSENGER  task  generates 

—  passengers  and  sends  a  signal  to  the  ELEVATOR  task.  The 

—  ELEVATOR  loads  and  imloads  passengers  emd  sends  a  signal  back 

—  to  the  PASSENGER  task  after  loading  new  arrivals  or  placing 

—  them  in  a  queue  (the  elevator  has  a  maximum  capacity,  the 

—  queue  holds  any  passengers  who  have  to  wait) . 


with  SYSTEM,  INTERRUPT.MANAGER,  TEXT.IO; 
procedure  MAIN  is 
—  user  signals 

SIGUSRl:  constant  SYSTEM . ADDRESS : *  INTERRUPT_MANAGER.SIGNAL(16) ; 
SIGUSR2;  constant  SYSTEM . ADDRESS : =  INTERRUPT.MANAGER. SIGNAL ( 17) ; 

subtype  PROCESS.ID  is  INTEGER; 

"  HP-UX  calls 

procedure  KILL  (PID  :  PROCESS.ID;  SIG  :  SYSTEM .ADDRESS) ; 
pragma  INTERFACE  (C,  KILL); 


function  GETPID  return  PROCESS.ID; 
pragma  INTERFACE  (C,  GETPID); 
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function  RAND  return  INTEGER; 
pragma  INTERFACE  (C,  RAND); 


MY.PID  :  PROCESS. ID  :=  GETPID; 

—  elevator  capacity,  directions,  floor  ntimbers, 

—  arriving  passengers 

MAX.CAPACITY  :  constant  ;*  16; 

type  DIRECTION  is  (NONE,  UP,  DOWN); 
subtype  MOTION  is  DIRECTION  range  UP  ..  DOWN; 

ARR.DIR,  CUR.DIR  :  MOTION; 

subtype  FLOOR  is  INTEGER  range  1  ..5; 

ARR.FLR,  CUR.FLR  :  FLOOR; 

ARR.PASS  :  INTEGER; 

—  random  floor  and  direction  selectors 

function  RAND.FLR  return  FLOOR  is 
begin 

return  (RAND  rem  (FLOOR’LAST  -  FLOOR’FIRST  +  1))  +  1; 
end  RAND.FLR; 

function  RAND.HOTION  return  MOTION  is 

MOTIONS  ;  constant  INTEGER  :=  MOTION’PJS  (MOTION ’LAST) 
-MOTION’POS  (MOTION ’FIRST); 

begin 

return  MOTION’VAL  (MOTION’POS(MOTION’FIRST) 

(RAND  rem  MOTIONS)); 

end  RAND.MOTION; 

—  show  passenger/floor  information 
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procedure  SHDW.PASS  (WHERE:  in  FLOOR;  PASS:  in  INTEGER; 

DOING:  in  STRING;  WHICH:  in  DIRECTION  :=  NONE)  is 

FNUM  :  constant  STRING  :=  FLOOR’IMAGE  (WHERE); 

PNUM  :  constant  STRING  ;=  INTEGER* IMAGE  (PASS); 

begin 

TEXT.IO.PUT  ("On  floor  "  ft  FNUM  ( (FNUM 'FIRST+1 ). .FNUM ’LAST) 
ft  "  there  "); 

case  PASS  is 

when  0  =>  TEXT.IO.PUT  ("are  no  passengers"); 

when  1  =>  TEXT.IO.PUT  ("is  1  passenger"); 

when  others  =>  TEXT.IO.PUT 

("are  "  ft  PNUM  ( (PNUM ’ FIRST+ 1) . .PNUM ’LAST) 
ft  "  passengers") ; 

end  case; 

TEXT.IO.PUT  (DOING); 
if  WHICH  I-  NONE  then 

TEXT.IO.PUT  (DIRECTION ’IMAGE(HHICH)  ft  "."); 
end  if ; 

TEXT.IO.NEW.LINE; 
end  SHOW.PASS; 

task  OUTPUT  is 

entry  LOCK;  —  This  task  implements  a  lock/unlock 

—  mechanism  for 

entry  UNLOCK;  —  output,  so  that  messages  do  not 

—  get  intermixed. 

end  OUTPUT; 
task  PASSENGER  is 

—  This  task  generates  passengers  at  various  floor  levels 

—  and  sends  SIGUSRl  to  the  ELEVATOR  task.  The  elevator 

—  task  sends  SIGUSR2  back  to  acknowledge  that  passengers 

—  have  been  served, 
entry  START; 

•entry  CONTINUE; 

for  CONTINUE  use  at  SIGUSR2; 
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end  PASSENGER; 


task  ELEVATOR  is 

—  This  task  loads  and  imloads  passengers, 
entry  START; 

entry  LOAD.ARRIVING.PASS; 
entry  UNLOAD; 
entry  LOAD.WAITING.PASS ; 
for  LOAD.ARRIVING.PASS  use  at  SIGUSRl; 
end  ELEVATOR; 

task  MANAGER  is 

—  This  task  determines  the  floor  nxunber  and  direction  of 

—  the  elevator.  It  calls  ELEVATOR  task  to  load  and  iinload 

—  passengers  on  each  floor, 
entry  START ; 

end  MANAGER; 

task  body  OUTPUT  is 
begin 
loop 

accept  LOCK; 
accept  UNLOCK; 
end  loop; 
end  OUTPUT; 

task  body  PASSENGER  is 
begin 

accept  START; 
loop 

ARR.FLR  :=  RAND.FLR;  —  Deteraine  the  floor  number, 
if  ARR.FLR  =  FLOOR’ FIRST  then 

ARR.DIR  :=  UP;  --  The  bottom  floor  only  goes  up 

elsif  ARR.FLR  *  FLOOR ’LAST  then 

ARR.DIR  :=  DOWN;  --  The  top  floor  only  goes  down. 

.  '  else 

ARR.DIR  :=  RAND.MOTION; 

—  Any  other  floor  can  go  either  way 
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end  if ; 

ARR.PASS  :=  RAND  rem  MAX.CAPACITY ; 

if  ARR.PASS  >  0  then 
OUTPUT. LOCK: 

SHOW.PASS  (ARR.FLR,  ARR.PASS, 

"  arriving  to  go  " ,  ARR.DIR) ; 

OUTPUT. UNLOCK; 
end  if; 

KILL  (MY.PID,  SIGUSRl): 

—  Send  SIGUSRl  to  the  ELEVATOR  task. 


accept  CONTINUE; 

—  Passengers  loaded  or  waiting  in  the  queue. 

end  loop; 
end  PASSENGER; 

task  body  ELEVATOR  is 

—  This  task  loads  and  unloads  passengers . 

—  It  loads  the  arriving  passengers  when  the  elevator 

—  arrives  on  the  right  floor  when  going  in  the  right 

—  direction.  Each  passenger  decides  which  floor  to  exit 

—  when  he  or  she  enters  the  elevator.  If  the  number  of 

—  passengers  exceeds  the  maximum  capacity,  the  excess 

—  passengers  have  to  wait  for  the  next  elevator  visit. 

LOADED.PASS  :  INTEGER  :=  0; 

DESTINATION  :  array  (FLOOR)  of  INTEGER  :=  (others  =>  0); 
WAIT  :  array  (FLOOR,  MOTION) 

of  INTEGER  :=  (others  =>  (0,  0)); 

procedure  CHOOSE.DEST  (FROM.FLOOR  :  FLOOR;  GOING  ;  MOTION; 

PASS  :  INTEGER)  is 

—  Each  passenger  picks  a  destination  floor. 

DEST.FLOOR  :  FLOOR; 
begin 

for  I  in  1  . .  PASS  loop 
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loop 

DEST.FLOOR  :*  RAND.FLR; 

—  The  destination  floor  should  be  different 

—  from  the  starting  floor  and  in  the 

—  desired  direction, 
if  GOING  *  UP  then 

exit  when  DEST.FLOOR  >  FROM.FLOOR; 
else 

exit  when  DEST.FLOOR  <  FROM.FLOOR; 
end  if ; 
end  loop; 

DESTINATION (DEST.FLOOR) :=  DESTINATION (DEST.FLOOR)  +  1; 
end  loop; 
end  CHOOSE.DEST; 

procedure  LOAD.PASS  (ARR.FLR  :  FLOOR;  ARR.DIR  :  MOTION; 

ARR.PASS  :  INTEGER)  is 
—  Load  the  new  arrivals  and  any  people 
—  waiting  in  the  queue. 

REQUEST.PASS  :  INTEGER 

WAIT  (ARR.FLR.  ARR.DIR)  +  ARR.PASS; 

TAKE  :  INTEGER; 

begin 

if  REQUEST.PASS  +  LOADED.PASS  >  MAX.CAPACITY  then 
TAKE  ;«  MAX.CAPACITY  -  LOADED.PASS; 
else 

TAKE  :=  REQUEST.PASS; 
er.d  if; 


CHOOSE.DEST  (ARR.FLR,  ARR.DIR,  TAKE); 

WAIT  (ARR.FLR,  ARR.DIR)  :*  REQUEST.PASS  -  TAKE; 
LOADED.PASS  :=  LOADED.PASS  ♦  TAKE; 

OUTPUT. LOCK; 
if  TAKE  >  0  then 

SHOW.PASS  (ARR.FLR,  TAKE, 

"  being  loaded  to  go  " ,  ARR.DIR) ; 

end  if ; 
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SHOW.PASS  (ARR.FLR,  LOADED.PASS,  "  on  the  elevator."): 
if  WAIT  (ARR.FLR,  ARR.DIR)  >  0  then 

SHOW.PASS  (ARR.FLR.  WAIT  (ARR.FLR,  ARR.DIR) , 

"  waiting  for  the  next  elevator  to  go  " ,  ARR.DIR) ; 

end  if; 

OUTPUT. UNLOCK; 
end  LOAD.PASS; 

begin  —  ELEVATOR 
accept  START  do 

PASSENGER. START;  —  Start  the  passengers, 
end  START; 

loop 

select 

when  CUR.FLR  *  ARR.FLR  and  then  CUR.DIR  *  ARR.DIR  => 
accept  LOAD.ARRIVING.PASS  do 

—  Load  new  arrivals  if  possible, 
if  ARR.PASS  >  0  then 

LOAD.PASS  (ARR.FLR,  ARR.DIR,  ARR.PASS); 
end  if ; 

—  Send  S1GUSR2  to  the  PASSENGER  task  to  inform 

—  that  passengers  are  either  loaded  or  put  in 

—  the  queue. 

KILL  (MY.PID,  SIGUSR2); 
end  LOAD.ARRIVING.PASS; 
or 

accept  UNLOAD  do 

—  Unload  passengers  whose  destinations  are  the 
—  current  floor, 
if  DESTINATION  (CUR.FLR)  >  0  then 
OUTPUT. LOCK; 

SHOW.PASS  (CUR.FLR,  DESTINATION  (CUR.FLR), 

"  being  unloaded  before  going  ",  CUR.DIR); 
OUTPUT. UNLOCK; 

LOADED.PASS  :=  LOADED.PASS  - 

DESTINATION  (CUR.FLR); 
DESTINATION  (CUR.FLR)  :*  0; 
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end  if ; 
end  UNLOAD; 
or 

accept  LOAD.WAITING.PASS  do 

—  Load  any  passengers  waiting  in  the  queue, 
if  WAIT  (CUR.FLR,  CUR.DIR)  >  0  then 
LOAD.PASS  (CUR.FLR,  CUR.DIR,  0); 
end  if; 

end  LOAD.WAITING.PASS; 
end  select; 
end  loop; 
end  ELEVATOR; 

task  body  MANAGER  is 

—  This  task  determines  the  floor  number  and  direction  of 

—  the  elevator.  It  calls  ELEVATOR  task  to  load  and  unload 

—  passengers  on  each  floor, 
begin 

accept  START  do 

--  Initialize  the  direction,  and  floor  number. 

CUR.DIR  UP; 

CUR.FLR  :=  FLOOR 'FIRST; 

ELEVATOR . START ;  —  Start  the  elevator, 
end  START; 

loop 

—  Unload  passengers  whose  destinations  are  the 
7"  current  floor. 

ELEVATOR. UNLOAD; 

—  Load  passengers  waiting  in  the  queue. 

ELEVATOR . LOAD.WAITING.PASS ; 

if  CUR.DIR  *  UP  then 

CUR.FLR  :=  CUR.FLR  +1; 
if  CUR.FLR  =  FLOOR 'LAST  then 

CUR.DIR  :=  DOWN;  --  Reached  the  top  floor, 

—  change  the  direction. 

end  if ; 
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else 

CUR.FLR  :*  CUR.FLR  -  1; 
if  CUR.FLR  =  FLOOR 'FIRST  then 

CUR.DIR  ;=  UP;  —  Reached  the  bottom  floor, 

—  cheujge  the  direction. 

end  if; 
end  if; 
end  loop; 
end  MANAGER; 

procedure  HANDLE.PASSENGER  (SIG  ;  SYSTEM. ADDRESS)  is 

—  This  is  the  handler  for  SIGUSRl.  It  calls  the  ELEVATOR 

—  task  to  load  the  new  arrivals, 
begin 

ELEVATOR. LOAD.ARRIVING.PASS; 
end  HANDLE.PASSENGER; 

procedure  ACKNOWLEDGE  (SIG  :  SYSTEM. ADDRESS)  is 

—  This  is  the  handler  for  SIGUSR2.  It  calls  the  PASSENGER 

—  task  to  continue  generating  passengers, 
begin 

PASSENGER. CONTINUE; 
end  ACKNOWLEDGE; 


begin  —  MAIN 


—  Initialize  the  interrupt  entry  manager. 
INTERRUPT.MANAGER . IN IT.INTERRUPT.MANAGER 
(NUMBER.OF.BUFFERS  =>  4, 
HAX.PARAM.AREA.SIZE  =>  1024, 
INTERRUPT.STACK.SIZE  =>  8024) ; 


—  Install  handlers. 

INTERRUPT.MANAGER . INSTALL.HANDLER 

(HANDLER. ADDRESS  =>  HANDLE.PASSENGER 'ADDRESS, 

SIG  =>  SIGUSRl , 

PRIORITY  =>  INTERRUPT.MANAGER. INTERRUPT.PRIORITY' LAST) ; 
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INTERRUPT.MANAGER . INSTALL.HANDLER 

(HANDLER. ADDRESS  =>  ACKNOWLEDGE ’ADDRESS, 

SIG  *>  SIGUSR2. 

PRIORITY  *>  INTERRUPT.MANAGER. INTERRUPT.PRIORITY’ FIRST): 

MANAGER. ST ART; 
end  MAIN; 
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F  12.12  Specification  of  the  package 
INTERRUPT.MANAGER 

package  INTERRUPT.MANAGER  is 

—  ^i^^m********************************************************* 

—  This  package  provides  support  for  signal  handlers. 

—  It  must  NOT  be  recompiled  as  it  is  already  compiled  in  the 

—  predefined  library. 

INTERRUPT.LEVELS  :  constant  7; 


—  Number  of  priority  levels  for  interrupt  entries. 


type  INTERRUPT.PRIORITY  is  range 

SYSTEM.PRIORITY’LAST  +  1  ..  SYSTEM. PRIORITY 'LAST 

♦  INTERRUPT.LEVELS; 
for  INTERRUPT.PRIORITY 'SIZE  use  32; 


This  type  defines  the  range  of  allowed  priorities  for  calls 
to  interrupt  entries. 


type  ACTION  is  (FIRST,  LAST,  REPLACED); 

for  ACTION  use  (FIRST  =>  0,  LAST  =>  1,  REPLACED  =>  2); 


—  This  type  defines  the  actions  to  be  taken  with  regeurd  to  the 

—  previous  handler  for  the  signal  (if  any): 

—  *  FIRST:  previous  handler  is  to  be  called  before 

—  the  Ada  handler. 

—  ♦  LAST:  previous  handler  is  to  be  called  after 

the  Ada  handler. 

—  *  REPLACED:  previous  handler  is  not  to  be  called. 
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type  BUFFER_NUHBER  is  range  0..2**15-1; 


—  Number  of  buffers  to  hold  parameters  of  interrupt  entry 

—  calls  that  cannot  be  processed  immediately. 


type  BYTE_SIZE  is  range  0..2**15-1; 


—  Used  to  specify  sizes  in  bytes. 


MAX.HANDLERS  :  constant  :=  32; 


—  Maximum  nvimber  of  installable  handlers . 


type  HANDLER.MUMBER  is  range  0. .MAX.HANDLERS; 


Number  of  installed  handlers. 


NO.FREE.BUFFERS  :  BOOLEAN  :=  FALSE; 


—  Set  to  TRUE  if  a  signal  could  not  be  handled  because  no 

—  buffer  was  available  to  hold  the  parameters.  (In  such  cases 

—  it  is  not  possible  to  raise  TASKING.ERRDR  because  the  entry 

—  call  was  not  made  by  a  normal  task.)  If  NO.FREE.BUFFERS 

—  becomes  true  it  is  recommended  that  the  number  of  buffers 

—  specified  when  calling  INIT.INTERRUPT.MANAGER  (see  below) 

—  be  increased,  or  if  possible  increase  the  priority  of  the 

—  called  task.  The  user  can  reset  this  variable  to  FALSE  at 

—  any  time. 


pragma  SHARED  (NO.FREE.BUFFERS); 
TASK.NOT.CALLABLE  :  BOOLEAN  :=  FALSE; 


Set  to  TRUE  if  a  signal  could  not  be  handled  because  the 
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—  called  task  was  not  callable  (it  was  completed  or 

—  terminated) .  The  user  can  reset  this  variable  to  FALSE 

—  at  any  time. 


pragma  SHARED  (TASK.NOT.CALLABLE) ; 


—  Signal  definition: 


type  SIGNAL.NUMBER  is  range  0..32; 
function  SIGNAL  is 

new  UNCHECKED.CONVERSIDN  (SIGNAL.NUMBER,  SYSTEM. ADDRESS) ; 

procedure  INIT.INTERRUPT.HANAGER 

( NUMBER. OF.BUFFERS  :  in  BUFFER.NUMBER; 
MAX.PARAM.AREA.SIZE  :  in  BYTE.SIZE; 
INTERRUPT.STACK.SIZE  :  in  BYTE.SIZE  :=  2048); 


—  This  procedure  allocates  the  specified  number  of  buffers  to 

—  hold  the  parameters  of  interrupt  entry  calls  that  cannot  be 

—  processed  immediately,  and  allocates  a  signal  stack  of  the 

—  given  size.  The  size  of  each  buffer  is  the  maximum 

—  parameter  area  size  plus  a  fixed  overhead  of  28  bytes  used 
--  by  the  Ada  runtime.  If  the  given  signal  stack  size  is  zero, 

—  all  signals  are  handled  on  the  current  stack,  and  all  stacks 

—  must  then  have  sufficient  buffer  space. 

—  This  procedure  must  be  called  before  any  Ada  signal  handler 

—  can  be  installed  and  hence  before  any  interrupt  entry  call 

—  can  be  made  from  an  Ada  signal  handler.  Signals  can  be 

—  lost  if  the  number  of  buffers  is  insufficient.  The  number 

—  of  buffers  required  depends  on  the  frequency  of  signals. 

—  The  number  of  buffers  can  be  specified  as  zero  if  all  Ada 

—  signal  handlers  completely  handle  their  signal  and  never 

—  call  an  interrupt  entry. 

—  This  procedure  raises  the  exception  STORAGE.ERROR  if  there 
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—  is  not  enough  memory  to  allocate  the  required  buffers  and/or 

—  the  signal  stack. 


procedure  INSTALL. HANDLER 

(HANDLER. ADDRESS  :  in  SYSTEM . ADDRESS ; 

SIG  :  in  SYSTEM . ADDRESS ; 

PRIORITY  :  in  INTERRUPT.PRIORITY 

:*  INTERRUPT.PRIORITY ’FIRST; 
ORIGINAL.HANDLER  :  in  ACTION  :*  REPLACED); 


—  This  procedure  installs  the  Ada  routine  at  the  specified 

—  address,  as  the  Ada  signal  handler  for  the  specified  signal, 

—  after  saving  the  address  of  the  current  signal  handler  (if 

—  any).  The  specified  priority  determines  the  priority  of  all 

—  entry  calls  made  by  the  handler  (all  accept  statements  will 

—  run  with  this  priority) . 

—  The  address  of  the  Ada  signal  handler  can  be  obtained  with 

—  the  attribute  ’ADDRESS  (which  is  only  valid  after 

—  elaboration  of  the  procedure  body).  The  Ada  signal  handler 

—  receives  control  with  the  signal  it  is  handling  blocked,  but 

—  other  non-reserved  signals  are  only  blocked  if  they  have  an 
"  Ada  signal  handler  routine  and  it  is  currently  active  (has 

—  been  called  in  response  to  the  signal  but  has  not  yet 

—  returned) .  The  Ada  signal  handler  must  not  make  implicit 

—  or  explicit  calls  to  the  Ada  runtime,  other  than  a  simple 

—  entry  call  to  the  interrupt  entry  with  the  address  clause 

—  corresponding  to  the  signal  being  handled.  Neither  timed 

—  nor  conditional  entry  calls  may  be  made  from  an  Ada  signal 

—  handler. 

—  The  Ada  signal  handler  must  be  a  procedure  with  one 

—  parameter  of  type  ADDRESS,  and  without  inner  units.  The 
--  procedure  can  only  reference  local  or  global  objects 

—  (excluding  objects  of  enclosing  frames).  The  Ada  signal 

—  handler  procedure  must  be  compiled  with  checks  off 
--  (using  the  -R  option) . 
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—  This  procedure  raises  the  exception  STORAGE.ERROR  if 
--  MAX.HANDLERS  handlers  have  already  been  defined. 


procedure  REMOVE.HANDLER  (SIG  ;  in  SYSTEM.ADDRESS) ; 


—  This  routine  removes  the  handler  for  the  given  signal  and 

—  restores  the  original  handler.  This  procedure  may  be  useful 

—  if  for  some  reason  the  task  that  normally  handles  this 

—  signal  is  temporarily  (or  permanently)  no  longer  able 

—  to  do  so. 

—  This  procedure  raises  the  exception  PROCRAM.ERRDR  if  no 

—  handler  has  been  installed  for  the  given  signal  number. 


function  HANDLER.COUNT  return  HANDLER.NUMBER; 


—  This  function  returns  the  number  of  installed  Ada  signal 

—  handlers. 


end  INTERRUPT.HANAGER; 
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F  12.13  Ada  Runtime  Routine  Descriptions 

Tables  12-1  through  12-7  lists  Ada  Runtime  System  routines  and  their 
function.  If  calls  to  any  of  these  routines  appear  in  your  Ada  handler,  the 
handler  is  “unsafe”,  as  described  in  section  “F  12.6  Associating  an  Ada 
Handler  with  an  HP-UX  Signal”. 


Table  12-1.  Heap  Management  Routines 


Routine 

Description 

ALLOC.GO 

Allocates  a  global  object. 

ALLDC.LO 

Allocates  a  local  object. 

ALLOC.TEMP 

Allocates  a  temporary  object. 

ALLOC_TEMP_GH 

Allocates  a  global  temporary  object. 

FREE.LIST 

Cleans  up  head  objects  at  the  end  of  a  block. 

FREE.TEMP 

Frees  a  temporary  object. 

FREE.TEMP.GH 

Frees  a  global  temporary  object. 

Table  12-2. 

Collection  Management  (no  storage.size  representation  clause) 


Routine 

Description 

ALLOC_SMALL_FIX_ELT 

Allocates  a  space  for  a  new  object  in  the  collection. 

FREE_SMALL_FIX_ELT 

Frees  the  space  allocated  to  the  object  of  the 
corresponding  collection. 

IHIT_SMALL_FIX_ELT 

Initializes  the  descriptor  for  a  collection  with  small 
and  fi.xcd  size  elements. 
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Table  12-3. 

Collection  Management  (collections  with  a  storage.size 
representation  clause) 


Routine 

Description 

Fixed  element  size 

ALLOC_FIX_SS_ELT 

Allocates  a  space  for  a  new  object  in  the  collection. 

FREE_FIX_Si>_rLT 

Frees  the  space  allocated  to  the  object  of  the 
corresponding  collection. 

INIT_FIX.SS_ELT 

Initializes  the  descriptor  for  a  collection  with  fixed 
size  elements. 

Variable  element  size 

ALLOC_VAR_SS.ELT 

Allocates  a  space  for  a  new  object  in  the  collection. 

FREE.VAR.SS.ELT 

Frees  the  space  allocated  to  the  object  of  the 
corresponding  collection. 

IKIT.VAR.SS.ELT 

Initializes  the  descriptor  for  a  collection  with 
variable  size  elements. 
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Routine 

Description 

ABORT.STMT 

Aborts  the  tasks  in  the  argument  lists  and  abort  all 
their  dependents. 

ACCEPT.STMT 

Implementation  of  a  simple  accept  statement. 

ACTIVATE_COLLECTIOK 

Called  after  the  elaboration  of  a  declarative  region 
that  contains  task  objects  and  at  the  end  of  the 
execution  of  an  allocator  of  an  object  with  one  or 
more  task  components.  This  routine  activates  a 
collection  of  tasks  in  parallel. 

COMPLETE.MASTER 

Called  when  exiting  a  block  or  subprogram  master 
unit  to  complete  a  master  unit  and  deallocate  its 
resource. 

COMPLETE.TASK 

Called  when  a  task  body  completion  point  is 
reached  and  is  about  to  execute  the  cleanup 
sequence  of  its  task  body  to  terminate  the  task  and 
its  dependents. 

COND.CALL 

Implementation  of  a  conditional  entry  call. 

COHD.SELECT 

Implementation  of  a  select  statement  with  an  else 
part. 

CREATE.TASK 

Called  when  a  single  task  specification  or  task 
object  declaration  is  elaborated  and  when  an 
allocator  is  executed  that  has  task  components. 

This  routine  creates  a  new  task  object. 

CURREKT_OBJECT_ 

OF_TASK_TYPE 

Called  when  a  task  is  referenced  from  the  task  body 
of  a  task  type.  This  routine  maps  a  task  unit  name 
to  the  referenced  task  when  the  unit  name  is  used 
to  refer  to  a  task  object  within  its  body. 

DELAY.STMT 

Implementation  of  a  delay  statement. 

Continued  on  the  next  page. 
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Table  12-4.  Tasking  Routines  (Continued) 


Routine 

Description 

DESTROY.COLLECTION 

Called  when  an  exception  is  raised  during  the 
execution  of  an  allocator  for  an  object  with  one  or 
more  task  components.  This  routine  terminates  any 
unactivated  tasks  in  the  collection. 

EID.ACTIVATIOM 

Called  at  the  end  of  a  successful  task  activation  to 
make  the  activated  task  eligible  to  run. 

ESTRY.CALL 

Implementation  of  a  simple  entry  call.  This  call  is 
safe  as  long  as  it  calls  a  task  entry  declared  as  an 
interrupt  entry  for  the  HP-UX  signal  that  caused 
the  Ada  signal  handler  to  be  invoked. 

EBV_TASK_MASTER 

Called  when  either  the  main  program  has  not  been 
invoked  and  a  library  package  is  being  elaborated, 
or  the  main  program  has  been  invoked  and  an 
allocator  is  to  be  executed  for  an  access  type  in  a 
library  package.  This  routine  initializes  an 
activation  collection  for  tasks  directly  dependent  on 
a  library  package. 

IlfIT.COLLECTION 

Called  at  the  beginning  of  a  unit  that  declares 
static  task  objects,  and  as  the  first  action  of  the 
execution  of  an  allocator  for  an  object  containing 
any  tasks.  This  routine  initializes  an  empty 
collection  of  tasks  to  be  activated  in  parallel. 

IHIT.HAHDLER 

Called  at  the  occurrence  of  an  address  clause  for  a 
task  entry.  This  routine  declares  that  an  entrv  is 
associated  with  an  interrupt  in  the  calling  task. 

Continued  on  the  next  page. 
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Table  12-4.  Tasking  Routines  (Continued) 


Routine 

Description 

ISIT.MASTER 

Called  at  the  beginning  of  a  master  unit  to  initialize 
an  internal  data  structure  MASTER.IHFO. 

IULL_BODY_ACCEPT_STMT 

Implementation  of  an  accept  statement  that  has  a 
null  statement  list  in  its  body. 

SELECT.WITH.TERMIIATE 

Implementation  of  a  select  statement  with  a 
terminate  alternative. 

SIMPLE.SELECT 

Implementation  of  a  select  statement  with  only 
accept  alternatives. 

SIMPLE_TIMED_SELECT 

Implementation  of  a  select  statement  with  one 
delay  alternative  without  a  guard  or  with  a  static 
open  guard. 

TERMIHATE.COMPLETE 

Called  when  task  body  is  complete  and  cleanups 
have  been  performed.  The  routine  propagates  the 
termination  information  up  the  hier^Lrchy  and 
deallocates  the  work  space;  the  run-time  schedules 
another  task. 

TIMED.CALL 

Implementation  of  a  timed  entry  call. 

TIMED.SELECT 

Implementation  of  a  select  statement  with  several 
delay  alternatives  or  with  one  guarded  delay 
alternative. 

12-32  F  12.  Interrupt  Entries 


Table  12*5.  Attributes  Routines 


Routine 

Description 

EHUM.POS 

Implementation  of  T’POS,  where  T  is  an 
enumeration  type. 

EIUM.WIDTH 

Implementation  of  T' WIDTH,  where  T  is  an 
enumeration  type. 

FIXED.FORE 

Implementation  of  T 'FORE,  where  T  is  a  fixed  point 
subtype. 

FIXED.LARGE 

Implementation  of  T ’LARGE,  where  T  is  a  fixed  point 
subtype. 

FIXED.MAirriSSA 

Implementation  of  T’MAKTISSA,  where  T  is  a  fixed 
point  subtype. 

IKTEGER.IMAGE 

Implementation  of  T’ IMAGE,  where  T  is  an  integer 
type. 

INTEGER.VALUE 

Implementation  of  T’VALUE,  where  T  is  an  integer 
type. 

IHTEGER.HIDTH 

Implementation  of  T'WIDTH,  where  T  is  an  integer 
type. 

Table  12*6.  Attributes  for  Tasks  Routines 


Routine 

Description 

CAUABLE 

Implementation  of  T’ CALLABLE,  where  T  is  a  teisk. 

COURT 

Implementation  of  E'COUNT.  where  E  is  an  entrv  of  a 
task 

TERHIHATED 

Implementation  of  T’ TERHIHATED,  where  T  is  a  task 
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Table  12-7. 

Support  for  Enumeration  Representation  Clauses  Routines 


Routine 

Description 

EHUMl.PRED 

Implementation  of  T’PRED  attribute  for  types  whose 
VAL  is  implemented  on  one  byte;  that  is,  types  with 
no  more  than  128  values. 

EHU«2_PRED 

Implementation  of  T'PRED  attribute  for  types  whose 
VAL  is  implemented  on  two  bytes;  that  is,  types  with 
more  than  128  values  but  less  than  32768  values. 

EHUM4_PRED 

Implementation  of  T’PRED  attribute  for  types  whose 
VAL  is  implemented  on  four  bytes;  that  is,  types 
with  more  than  32767  values. 

ENUMl.SUCC 

Implementation  of  T’SUCC  attribute  for  types  whose 
VAL  is  implemented  on  one  byte;  that  is,  types  with 
no  more  than  128  values. 

ENUM2.SUCC 

Implementation  of  T’SUCC  attribute  for  types  whose 
VAL  is  implemented  on  two  bytes;  that  is,  types  with 
more  than  128  values,  but  less  than  32768  values. 

ENUM4_SUCC 

Implementation  of  *SUCC  attribute  for  types  whose 
VAL  is  implemented  on  four  bytes;  that  is,  types 
with  more  than  32767  values. 

ENU«1_VAL_TO_POS 

Convert  T'VAL  to  T'POS  for  types  whose  VAL  is 
implemented  on  one  byte;  that  is,  types  with  no 
more  than  128  values. 

ENUM2_VAL_T0_P0S 

Convert  T’VAL  to  T’POS  for  types  whose  VAL  is 
implemented  on  two  bytes;  that  is,  types  with  more 
than  128  values,  but  less  than  32768  values. 

ENUM4_VAL_T0_P0S 

Convert  T’VAL  to  T’POS  for  types  whose  VAL  is 
implemented  on  four  bytes;  that  is,  types  with  more 
than  32767  values. 
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REMOVE-HANDLER,  12-11 
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run-time,  11-64,  11-67 
checks,  11-4 
system,  1-6 
runtime 

descriptions,  12-28 

S 

scalar  types 

Boolean  types,  11-8,  11-51 
calling  FORTRAN,  11-32 
calling  Pascal,  1 1-51 
character  types,  11-9 
enumeration  types,  11-7,  11-50 
FORTRAN,  11-33 
general  considerations,  11-6 
integer  types,  11-7,  11-33,  11-48 
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